Con la legge di bilancio 2022 approvata dal Parlamento il 30 dicembre 2021 sono state introdotte numerose misure per favorire la competitività del sistema produttivo del Paese, tra cui il Nuovo Patent Box.
Il nuovo regime patent box ha portato con sé una serie di novità tra cui, ad esempio, la fuoriuscita di beni immateriali come il know-how aziendale come elementi interessati dalla tassazione agevolata. Questo aspetto ha portato molte società a concentrarsi su altri beni immateriali agevolati, come i programmi per elaboratore.
Oltre che un’occasione in termini fiscali, aderire a questa possibilità del regime di tassazione agevolata può rappresentare uno spunto per molte società per fare il punto e riorganizzare l’assetto e la gestione dei processi di sviluppo software, i quali, per essenza stessa della materia, risultano essere tendenzialmente anarchici.
Security by design e security testing nello sviluppo del software: le soluzioni
Indice degli argomenti
Il nuovo regime di tassazione in sintesi
Il regime patent box è un regime opzionale di tassazione agevolata per i redditi derivanti dall’utilizzo, nel 2021 e anni successivi, dei seguenti beni immateriali giuridicamente tutelabili impiegati direttamente o indirettamente nello svolgimento della propria attività d’impresa:
- software protetto da copyright;
- brevetti industriali;
- disegni e modelli.
Il patent box, dunque, consente a tutti i soggetti titolari di reddito d’impresa, indipendentemente dalla natura giuridica, dalla dimensione e dal settore produttivo di appartenenza, incluse le stabili organizzazioni in Italia di residenti in Paesi con i quali è in vigore un accordo per evitare la doppia imposizione e con i quali lo scambio di informazioni è effettivo, di beneficiare di una superdeduzione.
Il nuovo beneficio, infatti, consiste nella maggiorazione, valevole ai fini Irpef, Ires e Irap, dei costi di ricerca e sviluppo sopra descritti in misura pari al 110%.
Patent box: aspetti di governance
Il patent box, per sua natura, è strettamente collegato ad attività c.d. di “Ricerca e Sviluppo”, e il nuovo regime non fa eccezione da questo punto di vista, anche nelle parti relative ai software. Gli investimenti operati nel settore dello sviluppo di programmi per elaboratori, infatti, dovrebbero riguardare progetti che hanno portato alla nascita di applicativi dal carattere innovativo che integrino il carattere di beni immateriali utilizzati, direttamente o indirettamente, nello svolgimento dell’attività di impresa.
In tali termini, risulta dunque di particolare importanza, innanzitutto, una procedura di censimento e classificazione degli applicativi utilizzati all’interno dell’impresa. Una possibile classificazione intuitiva potrebbe essere la seguente:
- software proprietario: applicativo sviluppato dalla società in seguito ad attività di ricerca e sviluppo;
- software ausiliario: applicativo utilizzato dalla società durante le attività di ricerca e sviluppo.
Una volta censiti e classificati i programmi per elaboratori utilizzati e/o sviluppati, un’altra buona prassi da implementare sarebbe quella di una corretta gestione delle risorse umane che partecipano attivamente ai processi di sviluppo. Il patent box, infatti, contempla anche le spese sostenute nei confronti di dipendenti e/o consulenti esterni che hanno preso parte al processo di realizzazione dell’applicativo.
A livello di procedure, dunque, delle possibili soluzioni che un’organizzazione potrebbe prendere sono:
- censimento degli sviluppatori (interni ed esterni) con relative mansioni, progetti di afferenza, e ore dedicate per progetto;
- verifica dei contratti con i dipendenti/consulenti al fine di essere certi che, per quanto riguardi gli aspetti di proprietà intellettuale legati allo sviluppo di programmi per elaboratore, la società abbia la piena titolarità (fatti ovviamente salvi i diritti di natura morale) dei software su cui si dovrà basare la richiesta di tassazione agevolata.
Aspetti di processo nel patent box
Entrando più nel merito, ora, di quelle che potrebbero essere gli aspetti gestionali legati allo sviluppo software, risulta essere di fondamentale importanza per una società adottare una procedura per la definizione e la gestione del ciclo di vita di un software, ossia di uno schema generale in cui sono definiti le varie fasi in cui si potrebbe ritrovare un software durante la sua “vita”.
Tale procedura dovrebbe contenere sia aspetti “tradizionali”, propri di tali procedure, sia aspetti connessi ad evidenziare la assoggezione del software al regime qui in esame. Saper, infatti, attribuire a un software un preciso stato, facilita la società a determinare chi sono i responsabili per la gestione dell’applicativo in quel momento e a ravvisare lo stato di avanzamento del processo di sviluppo.
Ovviamente, per via dei continui e, a volte, anche repentini progressi tecnologici che caratterizzano il mondo dell’informatica, difficilmente si potrà sempre collocare il software in maniera precisa lungo le varie fasi del ciclo di vita, ma la predisposizione ad avere una distinzione di questo tipo non può che portare ordine e organizzazione all’interno della società.
Di seguito forniamo un possibile esempio di ciclo di vita:
- attività di ricerca preventiva: a fronte di un progetto di sviluppo software vengono effettuate delle attività di ricerca per determinare se sul mercato esistono già soluzioni similari che potrebbero ricalcare l’applicativo che si dovrebbe produrre per chiudere il progetto;
- pre-produzione: in questa fase vi è la traduzione dei requisiti del progetto in specifiche formali e la progettazione dell’applicativo;
- produzione: fase di realizzazione del software;
- verifica e validazione: fase di testing;
- promozione (eventuale): fase di pubblicizzazione del software;
- distribuzione e supporto (eventuale): vendita del software e attività di manutenzione e aggiornamento periodico.
Una volta aver definito le fasi del ciclo di vita che meglio si adattano alla realtà aziendale, due altre importanti policy che dovrebbero essere adottate sarebbero:
- policy per lo sviluppo sicuro di software;
- policy per la regolamentazione della contaminazione con software FLOSS.
La prima policy ha come scopo quello di far integrare, nel ciclo di vita precedentemente definito, delle attività di verifica e rilevazione di possibili criticità dal punto di vista della sicurezza andando a inserire, dunque, anche la contemplazione non solo di requisiti funzionali bensì anche di sicurezza.
L’analisi dei requisiti di sicurezza, infatti, permette – tra le varie opportunità – la modellazione delle possibili minacce che potrebbero essere mosse all’applicativo in modo tale da agire preventivamente e adottare, fin dalle primissime fasi di progettazione, delle contromisure necessarie per impedire o quantomeno tentare di impedire che tali attacchi vadano a buon fine.
La seconda policy, invece, ha come obiettivo quello di regolamentare come si devono integrare eventuali librerie, porzioni di codice parziali/integrali di programmi licenziati con licenze FLOSS (Free and Libre Open Source Software).
Bisognerebbe fare attenzione, infatti, a problematiche di questo tipo in quanto, se è vero che diverse licenze – quali a titolo esemplificativo, la MIT License, l’Apache 2.0, le BSD licenses – non creano particolari problematiche in relazione a eventuali programmi derivati, vi sono invece alcune licenze – come quella GNU GPL (General Public License) – le quali sono caratterizzate dalla c.d. clausola di viralità. Scopo di questa clausola è permettere che lo status giuridico dell’opera originale distribuita con una GNU GPL si propaghi a tutte le eventuali ridistribuzioni e/o opere derivate dall’originale.
La volontà, infatti, è quella che tutto ciò che utilizzo anche solo parzialmente del codice licenziato sotto GNU GPL rimanga, poi, un software open source. Impartire, dunque, delle corrette metodologie di lavoro e sensibilizzare il personale su tali tematiche potrebbe evitare problematiche in sede di controlli riguardanti l’accertamento dell’attribuzione dei diritti di proprietà intellettuale (in particolare quelli di utilizzazione economica) dei programmi per elaboratore, ad esempio.
Conclusioni
Le società impegnate nello sviluppo di software non dovrebbero utilizzare solamente le logiche di business per l’impostazione dei loro progetti, ma un processo di sviluppo che sia pensato e costruito secondo precise logiche di governance permette di instaurare delle dinamiche efficienti e strutturate che poi riescono anche a prescindere dalle singole persone che operano all’interno della società in dato istante in quanto, formalizzando i processi, si permette anche un più agevole passaggio di conoscenza in caso di cambiamenti a livello di risorse umane impiegate.
In relazione al patent box 2022, infine, avere un processo strutturato ovviamente non può far altro che semplificare le eventuali pratiche burocratiche e fornire anche un ottimo set documentale a sostegno dell’ottenimento dei benefici fiscali qui esaminati, nonché a sostegno della impostazione del proprio modello in sede di possibili controlli da parte dell’Agenzia dell’Entrate.
@RIPRODUZIONE RISERVATA
