Il contratto dedicato allo sviluppo di un software è forse tra i più delicati negozi che un’azienda possa trovarsi ad approntare, specie perché l’esigenza di negoziare un’attività di scrittura software si sta facendo sempre più diffusa, con le imprese che hanno ad esempio esigenze di sviluppare app, di personalizzare il software che utilizzano per renderlo più efficiente, di sviluppare soluzioni web based per la loro attività e tante altre esigenze che passano necessariamente per la scrittura di codice dedicato.
La sicurezza informatica nello sviluppo del software: le buone regole da seguire
Indice degli argomenti
Il contratto di sviluppo software
La negoziazione di contratti del genere presenta, però, molteplici profili di criticità: stiamo parlando, infatti, di contratti che hanno a oggetto un bene immateriale protetto dal diritto d’autore, che in certi casi (parliamo delle cosiddette “computer-implemented inventions“) è suscettibile di un ulteriore livello di tutela, ovvero quello brevettuale, e che viene prodotto per un committente da un soggetto che a seconda della sua situazione soggettiva e delle scelte negoziali può essere considerato un appaltatore ovvero un professionista.
Inoltre, il software “prodotto” per conto del committente in realtà nella stragrande maggioranza dei casi è costituito da un “composto” di software realizzato ad hoc per il progetto e di software già presente sul mercato e inserito nel software sulla base delle licenze più disparate (e che potrebbero confliggere con gli scopi di uso prefissi da chi ha necessità di utilizzare quel software).
Ma forse il problema principale che incontra chi commissiona la scrittura del software è l’equivoco su che cosa verrà “consegnato” al termine del percorso di scrittura del software.
Codice sorgente vs. codice oggetto
I contratti di sviluppo software custom made in moltissime ipotesi scontano una asimmetria informativa davvero significativa fra committente e software house. Spesso, infatti, il committente ha un’idea di cosa vuole, ma non ha minimamente internalizzato le competenze in grado di comprendere (1) cosa è necessario fare per arrivare al prodotto che ha in mente e (2) cosa davvero gli serve ottenere per utilizzare il software come da sua intenzione.
Uno degli snodi più critici di questa asimmetria informativa è senz’altro quello che nasce dalla distinzione fra codice sorgente e codice oggetto.
Quando noi pensiamo alla consegna di un software per solito pensiamo alla consegna di istruzioni per un elaboratore, istruzioni che idealmente dovremmo poter “leggere” e se del caso far leggere a uno sviluppatore che dovesse succedere alla software house alla quale ci siamo inizialmente rivolti.
In realtà non è per nulla così.
Il codice così come è scritto dallo sviluppatore (e protetto dal diritto d’autore), prima della consegna viene nella stragrande maggioranza dei casi “tradotto” in linguaggio macchina, ovvero in linguaggio binario (zeri e uno) e inglobato nel tipo di file che verrà eseguito dai PC aziendali.
Questo accade con tutti i programmi commerciali di cui abbiamo licenza (ad esempio, non è certo possibile vedere il codice sorgente del programma Microsoft Word installato sul nostro PC, semplicemente perché questo è tradotto, o per meglio dire compilato prima di essere distribuito).
Per intenderci, il codice sorgente somiglia a questo:
print(“Hello, world!”)
#This program prints Hello, world!
Mentre il codice binario (codice macchina) che deriva dal codice che abbiamo appena visto potrebbe somigliare a questo:
01110000 01110010 01101001 01101110 01110100 00101000 00100010 01001000 01100101 01101100 01101100 01101111 00101100 00100000 01110111 01101111 01110010 01101100 01100100 00100001 00100010 00101001 00001010 00100011 00100000 01010100 01101000 01101001 01110011 00100000 01110000 01110010 01101111 01100111 01110010 01100001 01101101 00100000 01110000 01110010 01101001 01101110 01110100 01110011 00100000 01001000 01100101 01101100 01101100 01101111 00101100 00100000 01110111 01101111 01110010 01101100 01100100 00100001 00001010
È chiaro come la consegna di una tipologia di codice rispetto all’altra faccia una grandissima differenza per il committente, specie perché non è affatto scontato (sia operativamente che giuridicamente) riottenere dal codice macchina il codice sorgente (attraverso un processo definito di de-compilazione).
A complicare ulteriormente la questione c’è la distinzione che si deve fare tra i linguaggi di programmazione compilati e quelli interpretati. Mentre i primi rientrano nel caso precedentemente visto, i secondi sono caratterizzati dal fatto che il codice sorgente non viene elaborato una tantum dal processo di compilazione, ma viene eseguito ogni volta da un apposito software, l’interprete, che lo “traduce” al volo in codice eseguibile dall’elaboratore elettronico.
Questa tipologia di linguaggi è impiegata ogni volta che si deve garantire la portabilità del codice su piattaforme diverse (per architettura della CPU, sistema operativo ecc.), per cui utilizzando l’interprete specifico per ciascuna piattaforma il codice sorgente di fatto risulterà “universale”. PHP, Python e Ruby – solo per citarne alcuni – sono tra i più diffusi linguaggi interpretati.
Moltissime applicazioni sviluppate per il web (dai siti Internet agli e-commerce, fino a complesse applicazioni specifiche) utilizzano linguaggi interpretati, e ciò dovrebbe dare un’idea della vastità dello scenario.
La scelta del linguaggio di programmazione rientra nei requisiti non funzionali di un’applicazione e ha implicazioni tecniche che il committente, senza un supporto professionale, non è in grado di valutare e che spesso delega inconsapevolmente allo sviluppatore: pertanto, parlando della proprietà del codice sorgente di un linguaggio interpretato, il più delle volte nascono pericolosi fraintendimenti.
A questo punto, infatti, si arriva alla questione complicata: quando il codice scritto per esempio in PHP viene rilasciato dallo sviluppatore, che potrebbe addirittura installarlo su un server di proprietà del committente, ne consegue automaticamente che venga trasferita anche la proprietà? Di fronte alla disponibilità “fisica” del codice sorgente, il committente di solito ritiene di sì; in realtà, per il codice sorgente di un linguaggio interpretato valgono le stesse norme del codice sorgente di un linguaggio compilato. E la sorpresa, per il committente, potrebbe essere amara.
SecDevOps: perché è da preferire a DevSecOps e come introdurlo in azienda
Il “problema” del codice sorgente
Per inquadrare la problematica della “consegna” dei codici sorgente e/o oggetto è opportuno premettere che entrambi sono oggetto di tutela autoriale. Il codice sorgente infatti è l’oggetto della “creazione” dell’autore, mentre il codice oggetto è la sua traduzione in una forma idonea a realizzare lo scopo per cui il codice è scritto.
Nel più ampio contesto, quindi, della disciplina dei diritti d’autore in seno al contratto di sviluppo software, si inserisce quindi la specifica problematica della consegna del codice sorgente e delle sue modalità.
Esaminiamo, ad esempio, il caso in cui il committente, magari per non aver compreso il contenuto del contratto con la software house incaricata di sviluppare per suo conto un applicativo e le conseguenze dell’accettare la consegna del solo codice compilato, sia in possesso del solo codice oggetto dell’app da lui richiesta.
All’inizio potrebbe procedere tutto senza intoppi, con il cliente soddisfatto del funzionamento del “prodotto” software e in grado di sfruttarlo integralmente.
Dopo un po’ di tempo potrebbero, però, sorgere esigenze di aggiornare i sistemi aziendali, oppure di aggiornare il software magari per rispondere a nuove esigenze degli utenti o a nuove esigenze normative.
A quel punto il committente proverà a rivolgersi alla software house che ha scritto il codice, ma potrebbe incontrare delle difficoltà, sia in termini economici (la software house, in posizione di sostanziale monopolio, essendo l’unica in grado di soddisfare la domanda di intervento del committente riposando sulla disponibilità del codice sorgente, potrebbe avanzare una richiesta troppo esosa) che in termini pratici (la software house potrebbe essere nel frattempo venuta meno per tutta una serie di ragioni o anche, banalmente, aver perso o non conservato il codice sorgente).
Il Software Assurance Maturity Model (SAMM) per lo sviluppo sicuro del software: la guida pratica
Cosa è possibile fare a questo punto, disponendo del solo codice oggetto?
Ed è bene precisare che il problema del “possesso” del codice sorgente è risolto solo in apparenza dall’utilizzo di un codice scritto in linguaggio interpretato (che viene consegnato non in linguaggio macchina ma in una versione “leggibile” dall’uomo) questo per un duplice ordine di motivi:
- alla consegna del codice non segue sempre la consegna dei lavori preparatori e dei commenti (essenziali per facilitare l’attività da parte di un diverso sviluppatore);
- alla consegna “fisica” del codice non consegue una situazione giuridica assimilabile al “possesso” dello stesso.
Sebbene in questi casi il livello di contenzioso sia meno elevato (non ci si scontra con la necessità di ottenere “qualcosa” dalla software house avendo questa già consegnato il codice nella sua forma leggibile da un essere umano), le problematiche giuridiche non sono meno insidiose.
Le soluzioni (negoziali) proposte per il codice sorgente non disponibile al committente valgono quindi allo stesso modo anche per il codice in linguaggio interpretato.
Tornando però all’esempio iniziale della diade codice sorgente/codice oggetto, va evidenziato che passare da un software compilato al codice sorgente è un’operazione non banale dal punto di vista tecnico, esistono infatti numerosi strumenti studiati per “confondere” i decompilatori e rendere così l’attività di decompilazione estremamente incerta e complessa.
Ma l’attività di decompilazione, oltre a ciò, è anche del tutto illegale, a mente dell’art. 64 quater della legge sul diritto d’autore (L. 633/41).
La decompilazione è infatti un’attività di traduzione della forma del software ed è vietata salvo sia necessaria per raggiungere l’interoperabilità.
Peraltro l’attività di decompilazione finalizzata al raggiungimento dell’interoperabilità è presidiata da una serie di requisiti e obblighi, davvero stringenti.
La decompilazione finalizzata all’ottenimento dell’interoperabilità presuppone:
- che il soggetto che dà corso all’attività sia licenziatario del software su cui opera o comunque abbia diritto di usare una copia del programma;
- che le informazioni per ottenere l’interoperabilità non siano già facilmente reperibili e rapidamente accessibili;
- che la decompilazione sia indispensabile per ottenere l’interoperabilità e limitata a quelle parti del programma originale necessarie per conseguirla;
- che le informazioni acquisite non siano comunicate a terzi;
- che le informazioni acquisite non siano utilizzate per costruire programmi sostanzialmente simili nella loro forma espressiva.
È quindi evidente come l’attività di de-compilazione sia attività difficile oltreché rischiosa dal punto di vista giuridico.
Il soggetto che abbia acquistato il solo codice oggetto dovrà quindi rivolgersi alla software house alla quale ha originariamente commissionato il codice per risolvere il problema (sempre che sia ancora in attività), in una relazione protratta nel tempo che magari l’imprenditore non aveva nemmeno ipotizzato all’inizio del rapporto fra le parti, pensando di potersi agilmente rivolgere alla concorrenza una volta ricevuto l’applicativo.
Quali sono le soluzioni per ovviare a questo problema?
Innanzitutto è opportuno capire cosa accade se nulla viene disciplinato fra le parti. Cosa dovrà consegnare lo sviluppatore? Il solo codice oggetto o anche il codice sorgente?
La questione è ampiamente dibattuta in giurisprudenza. Si registra però una direttiva giurisprudenziale per cui nel caso in cui il committente si sia rivolto ad uno sviluppatore individuale lo stesso avrà diritto alla consegna del codice sorgente (nonché ad un indennizzo nel caso di ritardata consegna dello stesso).
In questo senso si è ad esempio espresso il Tribunale di Bologna, Sez.Specializzata in materia di impresa, con la sentenza n. 96/2020.
Il Tribunale fa leva sulla disposizione della Legge 633/1941 per cui del software e/o della banca dati sviluppati dal dipendente durante la prestazione lavorativa giova (in termini di diritti di utilizzazione economica) il datore di lavoro.
Ai sensi della Legge 81/2017 (art. 4) questo principio è in certa misura riproposto nel caso di lavoro autonomo, con la previsione secondo la quale nel caso in cui “l’attività inventiva [recte inventiva e/o creativa] sia prevista come oggetto del contratto di lavoro e a tale scopo compensata” i relativi diritti di utilizzazione economica vengono trasferiti in capo al committente.
La soluzione dipende quindi in certa misura dalla lettera del contratto fra le parti (ovvero dalla definizione dell’oggetto del contratto, tenendo sempre presente che le cessioni dei diritti d’autore vanno provate per iscritto) e fatica ad essere estesa argomentativamente all’ipotesi di contratto di sviluppo commissionato, come spesso accade, non ad un lavoratore autonomo bensì ad una società.
La soluzione migliore è quindi quella di negoziare espressamente fra le parti il destino del codice sorgente, così da evitare sorprese un domani.
Questa negoziazione consente anche di negoziare la sorte dei lavori preparatori alla stesura del codice (che comprendono ad esempio le carte di flusso e sono spesso essenziali sia che si tratti di codice compilato sia che si tratti di codice interpretato), a volte anche più importanti del codice stesso nel caso in cui un soggetto diverso dall’autore sia chiamato a rielaborarlo, e il cui onere di consegna non può essere “presunto” in difetto di espressa pattuizione.
La negoziazione del destino del codice sorgente non coincide però necessariamente con la previsione della sua consegna.
Esistono infatti numerosi casi in cui la consegna del codice sorgente non trovi la disponibilità dello sviluppatore o comunque non sia conveniente.
Ad esempio, per risparmiare nell’immediato un committente potrebbe voler scientemente lasciare allo sviluppatore il codice sorgente, puntando così su un abbattimento del prezzo iniziale.
Alla “conservazione” del codice sorgente in capo allo sviluppatore possono poi essere agganciate ulteriori disposizioni circa l’ulteriore sfruttamento economico dell’opera dell’ingegno (sempre in ottica di abbattimento dei costi di sviluppo per la committenza ad esempio potrebbe essere previsto che lo sviluppatore possa commercializzare il software anche a terzi, magari evitando alcuni concorrenti diretti del committente quantomeno per un certo lasso di tempo).
Eppure, anche in queste ipotesi, potrebbe essere necessario per il committente intervenire sul software, e fisicamente impossibile accedervi perché nel frattempo la software house ha cessato la propria attività di impresa.
Cosa fare in questi casi?
Il software libero, tra digitalizzazione e condivisione: il ruolo delle community
Le soluzioni (consegna, escrow, smart contract)
Nel negoziare un contratto di sviluppo software la “via maestra” per disinnescare il problema del codice sorgente passa per la consapevolezza del problema e per la disciplina contrattuale chiara della sorte del codice.
Per il committente la soluzione negoziale migliore è certo quella di ottenere il codice sorgente (in una con i conseguenti diritti di sfruttamento economico del software che gli consentano di operare con libertà sul software stesso).
Il problema del codice sorgente non può però essere ignorato nemmeno nel caso in cui il committente, per lo scarso potere contrattuale o per la volontà di risparmiare sui costi di sviluppo, non ottenga la consegna del codice (e/o i diritti connessi, specie nel caso di codice in linguaggio interpretato) ma anzi accetti una disciplina della cessione dei diritti di sfruttamento economico dell’opera particolarmente “limitata” tale da equipararlo ad un semplice licenziatario.
In questi casi il committente ha la possibilità, in quanto legittimo acquirente del software, di adattarlo o trasformarlo (se questo è necessario per il suo utilizzo in modo conforme alla sua destinazione), di trarre dal programma tutte le informazioni necessarie per migliorare la sua operatività e di effettuare una copia di backup.
Se vuole aggiornare il software, migliorarlo, integrarlo con altri strumenti o comunque effettuare nuovi interventi che vadano oltre “l’utilizzo in modo conforme alla sua destinazione” del software, il committente dovrà però necessariamente risolversi alla software house che ha sviluppato il programma.
Sorge però un problema nel caso in cui la software house nel frattempo sia venuta meno per i più svariati motivi.
E il problema è di assoluta rilevanza perché la disponibilità del codice sorgente può rivelarsi essenziale nel caso sia necessario risolvere bug, anche critici e paralizzanti, sul software.
In questi casi è chiaro che in mancanza del codice potrebbe tramutarsi in un danno notevole per l’azienda che ha sovvenzionato lo sviluppo del programma.
Del resto se non lo si disciplina in contratto, la software house non ha certo un obbligo di conservare per anni il codice sorgente e quindi non le potrà essere imputata l’incapacità di sottoporlo al cliente, magari perché semplicemente ha smarrito il codice.
Il codice sorgente è quindi un elemento essenziale dello sviluppo del software ed è importante che il committente, se non ottiene la consegna del codice, individui negozialmente degli strumenti per ottenere comunque il codice sorgente nel momento in cui la software house a cui ha commissionato lo sviluppo iniziale del programma non sia più in grado di assisterlo.
Esistono varie soluzioni che consentono di evitare di perdere un investimento rilevante solo per l’indisponibilità del codice sorgente, senza necessariamente passare per la sua consegna al committente.
Una delle soluzioni più interessanti è quella dell’escrow, una clausola negoziale per cui lo sviluppatore si impegna a stipulare un contratto con una terza parte che fungerà da depositario del codice e lo metterà a disposizione della committenza in una serie di ipotesi predeterminata (ad esempio la chiusura, la liquidazione, o il fallimento della software house, ma anche ipotesi quali il suo prolungato inadempimento, etc.).
Lo stesso vale per elementi accessori o ancillari al codice interpretato (es. la versione commentata del codice e i lavori preparatori), che possono essere negoziati in identica pattuizione laddove non se ne preveda la consegna.
In questa serie di ipotesi il committente, documentando l’accaduto, potrà rivolgersi al depositario del codice sorgente ed ottenerlo per porre in essere le operazioni necessarie all’ulteriore sviluppo del programma.
Di fatto stiamo parlando di una ulteriore cessione dei diritti di sfruttamento economico dell’opera condizionata al verificarsi di una serie di eventi specifici.
Il terzo garante, tipicamente un notaio, da un lato garantisce che il codice sorgente venga mantenuto per una durata predeterminata (e solitamente parametrata al ciclo di vita del software) e dall’altro garantisce imparzialità nell’applicare le regole pattizie convenute dalle parti, regolando l’accesso nel rispetto di queste e della legge.
Si stanno però affacciando sul mercato numerose soluzioni online ed automatizzate per garantire la gestione ottimale (anche in senso economico) dell’escrow. Tra l’altro numerosi di questi servizi consentono anche di sottoporre a verifica il codice sorgente consegnato, così da garantire che un domani questo sia davvero utile al committente per proseguire nello sviluppo del programma.
Se il contenzioso in tema di codice sorgente ci insegna qualcosa è che spessissimo quando la software house, volente o nolente, consegna il codice sorgente, i problemi non sono finiti, ma si apre un’ulteriore appendice contenziosa tesa a verificare se davvero stiamo parlando del codice sorgente completo e se questo codice è stato steso seguendo degli standard tali da consentire ad un altro sviluppatore di riprendere il lavoro senza sfibranti opere di “interpretazione” di quanto scritto da altri.
Molti servizi online offrono così dei servizi di “verifica” del codice consegnato basati sulla corrispondenza fra codice oggetto e codice sorgente, su verifiche del rispetto dei coding standard previsti per il linguaggio di programmazione utilizzato, e su test di funzionamento.
Il contratto di escrow è poi tipicamente oggetto di smart contract, che automatizzano il “rilascio” del codice sorgente ad esempio custodendo la password di decrittazione del codice (già consegnato ma in forma crittografata al cliente) fino a quando questa non viene “aperta” con il consenso di due delle parti del contratto trilaterale di escrow (tipicamente committente e software house oppure soggetto garante e software house). Il sistema, se ha dei vantaggi in termini di garanzia di funzionamento nel tempo, non si adatta bene alla necessità di verificare che il file criptato e consegnato sia effettivamente il codice sorgente di cui poi necessiterà il committente.
Le soluzioni quindi per ovviare al problema del codice sorgente sono numerose e variegate, l’importante però è che le parti del contratto affrontino la questione e la risolvano con chiarezza e lungimiranza.
La documentazione di progetto
Si è accennato in precedenza ai lavori preparatori e alla loro importanza per lo sviluppo di un’applicazione software. Prima di affidare la realizzazione di qualsiasi software, è fondamentale infatti dedicare il tempo necessario alla sua progettazione, raccogliendo sia i requisiti funzionali (come ci si aspetta che funzioni l’applicazione) sia i requisiti non funzionali (vincoli tecnologici, integrazioni con altri sistemi ecc.).
Le aziende spesso sottovalutano l’impegno che dovranno dedicare per trasferire le proprie conoscenze, oltre che i propri obiettivi, alla software house incaricata della realizzazione del software.
Il più delle volte all’inizio di un progetto il committente non percepisce il valore di tale know-how. Tuttavia, è bene tenere presente che, se non viene regolato contrattualmente, nulla o quasi vieta alla software house di sfruttare le conoscenze acquisite, per esempio creando altre applicazioni o erogando servizi che potenzialmente potrebbero avvantaggiare un concorrente del committente originale. I contenziosi in questi casi sono delicati e di esito sempre incerto.
L’attività di analisi è propedeutica allo sviluppo vero e proprio e permette di creare i documenti sulla base dei quali una o più software house possono formulare le proprie proposte economiche, confrontabili tra loro, permettendo di definire meglio tempi e costi del progetto. Quando l’analisi viene proposta dalla software house a cui si intende affidare lo sviluppo, è sempre bene scorporarne il relativo costo.
Il grado di dettaglio della documentazione all’avvio di un progetto dipende in larga parte dalla metodologia di sviluppo adottata. La tendenza è utilizzare modalità agili, volte cioè a rilasciare le funzionalità che identificano una tappa, o milestone, appena possibile affinché alcuni utenti chiave possano collaudarle e dare un riscontro immediato agli sviluppatori: questa modalità di sviluppo va incontro a quei committenti che, per forma mentis o per la dimensione del progetto, faticano a mettere a fuoco il quadro completo senza “toccare con mano” il risultato.
Se questo è lo scenario auspicabile, nella realtà è più frequente trovarsi di fronte a progetti che partono con obiettivi più o meno definiti e con requisiti funzionali continuamente ripensati scambiati a suon di e-mail – quando va bene – o messaggi WhatsApp.
È evidente però che, dato l’impegno a cui è chiamato il committente, non strutturare le informazioni e le conoscenze scambiate con la software house in una documentazione di progetto efficace costituisca una perdita notevole; inoltre, ciò rende più difficoltoso il controllo dei risultati e dei relativi costi.
A corredo della documentazione di progetto, si dovrebbe prevedere, anche contrattualmente, che le modifiche del codice sorgente siano documentate in un changelog: si tratta di uno strumento che aiuta gli sviluppatori che eventualmente dovessero subentrare in fasi successive a raccapezzarsi nel lavoro di chi li ha preceduti.
Inoltre, non si devono dimenticare le fasi successive al rilascio: i software migliorano con l’utilizzo da parte degli utenti, che ne segnalano malfunzionamenti o lacune; pertanto, la documentazione di progetto dovrebbe venire costantemente aggiornata.
In definitiva, è fondamentale dotarsi di strumenti di project management, bug tracking e feature request che consentano di documentare tutta la vita del software, dalla sua concezione al suo miglioramento.
Le modalità e gli strumenti con cui queste informazioni devono essere registrate e gestite dovrebbero pertanto essere regolati nel contratto di sviluppo software o dalle integrazioni che riguardano l’assistenza per la manutenzione correttiva o evolutiva. Se per il committente può risultare troppo oneroso dotarsi di queste soluzioni a supporto dello sviluppo, può quantomeno prevedere che se ne faccia carico la software house, a patto che la stessa si impegni a restituire l’archivio (ed eventualmente a distruggere la propria copia) al termine della collaborazione.
Altre criticità del contratto di sviluppo software
Aprendo questa disamina abbiamo ricordato che il contratto di sviluppo software è forse uno dei più delicati da affrontare, questo è vero non solo per il problema che abbiamo affrontato del codice sorgente, ma anche per una serie di ulteriori problematiche da tenere in considerazione.
Il contratto di sviluppo software incontra infatti (e si scontra con) molteplici problematiche, che vanno dalla necessità di disciplinare il collaudo del programma a quella di regolare la manutenzione del software, così come i livelli di servizio, o anche le possibilità di modifiche in corso d’opera da parte della committenza, ma forse il problema più complesso è quello di determinare l’oggetto del contratto, ovvero cosa davvero serve al committente, come vorrà usare il software, su quali sistemi e in quali condizioni d’uso.
Un altro punto da tenere in considerazione è quello di disciplinare le sorti del software “invenzione”, ovvero del software che realizza un effetto tecnico, in quanto per il committente è evidente come non sia auspicabile trovarsi un domani spogliato della possibilità di brevettare la sua invenzione, pur curata nel lato software dallo sviluppatore, perché quell’aspetto essenziale dell’attività inventiva è attribuibile ad un altro soggetto che ora non intende dare il suo assenso alla registrazione congiunta del trovato.
Gli ulteriori problemi derivano, come anticipato, dal fatto che quando parliamo di software parliamo di un prodotto dell’ingegno che la normativa equipara ad un prodotto editoriale o musicale, dotandolo di una tutela forte, automatica e in parte non rinunciabile.
Va infatti considerato che i soggetti coinvolti nel processo dello sviluppo software si troveranno necessariamente a “condividere” in certa misura un’opera autoriale (sempre ammesso che il software abbia carattere creativo).
I diritti morali rimangono infatti in capo all’autore o agli autori (persone fisiche), che avranno comunque diritto di opporsi a qualsiasi deformazione, mutilazione od altra modificazione dell’opera che possa essere di pregiudizio al suo onore o alla sua reputazione.
La tutela dei diritti morali può causare severe problematiche specie nel caso di codice destinato ad essere accessibile in certa misura via web, destinato ad essere rimaneggiato da terzi e potenzialmente alterato in maniera che l’autore potrebbe considerare pregiudizievole.
I diritti morali dell’autore sono inoltre inalienabili, imprescrittibili e irrinunciabili.
In questi casi sarebbe quindi opportuno, per quanto possibile, mettere a parte direttamente gli autori dell’uso che si intende fare del software e delle possibili evoluzioni del progetto, chiedendo la loro approvazione. L’autore infatti non può opporsi alle modifiche da lui conosciute ed accettate.
