Diritti, decompilazione e “segnali di allarme” nei contratti software

Di chi è il software, sul serio?

Uno dei problemi più frequenti – e allo stesso tempo più sottovalutati – nei contratti software riguarda una domanda apparentemente semplice: chi è davvero il titolare del programma e quali diritti ha chi lo commissiona o lo utilizza. Molte imprese sono convinte di “acquistare” un software, ma nella pratica ottengono soltanto una licenza d’uso, cioè un diritto limitato a utilizzare il programma entro confini ben precisi.

La differenza non è teorica. Diventa decisiva quando il rapporto con il fornitore si interrompe, quando il software smette di funzionare o quando occorre modificarlo, aggiornarlo o integrarlo con altri sistemi. In questi casi, scoprire di non avere i diritti necessari può tradursi in un blocco operativo totale.

Dal punto di vista giuridico, la cornice è chiara. In base alla Legge sul diritto d’autore (Legge 633/1941), il software è un’opera protetta al pari di un libro o di una composizione musicale. Chi scrive il codice è, per legge, titolare dei diritti patrimoniali, salvo che un contratto scritto non preveda espressamente la loro cessione al committente (art. 64-bis LDA). In assenza di una clausola chiara, l’utilizzatore non può modificare, copiare, decompilare o cedere il programma oltre quanto consentito dalla licenza.

Esiste una prima, importante eccezione: il software sviluppato dal dipendente nell’ambito delle proprie mansioni. In questo caso, i diritti patrimoniali spettano automaticamente al datore di lavoro, per effetto dell’art. 12-bis LDA. Qui la legge tutela l’investimento dell’impresa senza bisogno di ulteriori pattuizioni.

Negli ultimi anni, però, la giurisprudenza italiana ha iniziato a spingersi oltre il dato letterale della norma. Una pronuncia significativa del Tribunale di Bologna ha infatti applicato per analogia l’art. 12-bis anche allo sviluppo affidato a programmatori esterni, quando ricorrono alcune condizioni sostanziali:

• il software è realizzato su specifiche dettagliate del committente,
• è destinato a un uso esclusivo da parte di quest’ultimo,
• lo sviluppatore è remunerato per eseguire un progetto altrui e non per creare un prodotto autonomo.

In questo scenario, i giudici hanno riconosciuto che i diritti patrimoniali possono spettare al committente anche in assenza di una cessione scritta. Il messaggio è chiaro: conta la sostanza del rapporto, non solo la forma del contratto. Un’impresa che finanzia integralmente lo sviluppo e governa le scelte progettuali non può essere ridotta al ruolo di semplice licenziataria di ciò che ha già pagato.

Accanto al tema della titolarità, c’è poi un altro nodo cruciale: l’accesso al codice sorgente. Il sorgente è la versione “leggibile” del software, quella che consente a un tecnico di intervenire concretamente sul programma. Senza di esso, il cliente è totalmente dipendente dal fornitore, anche per correggere errori critici. Eppure, molti contratti – anche nel settore pubblico – tacciono completamente su questo punto.

Una soluzione diffusa, ma ancora poco utilizzata, è il deposito in escrow del codice sorgente: il sorgente viene affidato a un soggetto terzo e rilasciato al committente solo in casi predeterminati, come il fallimento del fornitore o l’interruzione del servizio. Non è una garanzia teorica, ma uno strumento di continuità operativa.

In sintesi, pagare lo sviluppo di un software non significa poterne disporre liberamente. Senza clausole chiare, il rischio è di trovarsi vincolati a un fornitore anche quando il rapporto non funziona più. Per questo, un contratto ben costruito deve chiarire fin dall’inizio:

• chi è titolare dei diritti d’autore,
• chi può accedere e intervenire sul codice sorgente,
• cosa accade se il rapporto contrattuale si interrompe.

La giurisprudenza sta aprendo spiragli importanti per tutelare i committenti anche in presenza di contratti lacunosi. Ma affidarsi ai tribunali è sempre l’ultima linea di difesa. Il vero punto di equilibrio si gioca prima, nella scrittura del contratto.

Ed è proprio quando il software smette di funzionare – o quando il fornitore non collabora più – che emerge una domanda ancora più delicata: fino a che punto l’utente può intervenire direttamente sul programma, anche arrivando a decompilarlo? È qui che il diritto d’autore incontra i suoi limiti più concreti.

Decompilare il software è legale, oppure no?

Per anni, molte aziende e pubbliche amministrazioni si sono sentite dire che “non si può toccare il codice del programma” perché coperto dal diritto d’autore. Ma cosa succede quando un software ha un errore che impedisce il suo normale funzionamento e il fornitore non interviene o non è più disponibile? È legittimo per l’utente cercare di risolvere il problema da solo, anche se significa “decompilare” il programma?

Nel 2021, la Corte di Giustizia dell’Unione Europea ha risposto con una sentenza chiara nel caso Top System (C-13/20): sì, è possibile decompilare un software per correggere errori, anche senza il permesso dell’autore. A condizione, però, che chi lo fa sia un utilizzatore legittimo del programma.

Secondo l’art. 5(1) della Direttiva 2009/24/CE, “in the absence of specific contractual provisions, the acts referred to in Article 4 (a) and (b) shall not require authorization by the rightholder where they are necessary for the use of the computer program by the lawful acquirer in accordance with its intended purpose, including for error correction.”

Questo significa che la persona o l’organizzazione che ha acquistato regolarmente una licenza può compiere anche atti riservati all’autore (come la riproduzione o la modifica del codice) se necessari per l’uso normale del programma, inclusa la correzione di errori.

La Corte spiega che la decompilazione, da un punto di vista tecnico, non restituisce il codice sorgente originale, ma produce una “terza versione” del programma, comprensibile quanto basta per essere rimaneggiata e ricompilata in un software funzionante. Da un punto di vista giuridico, la decompilazione “entails the reproduction and alteration of the code”, cioè due attività che normalmente sono riservate all’autore. Tuttavia, in caso di malfunzionamento, questi atti possono rientrare nelle eccezioni previste dall’art. 5.

La Corte è netta: “the lawful acquirer of a computer program may decompile software to correct errors affecting the program’s functioning without the rightholder’s authorization.” In altre parole, se il programma è difettoso e non fa quello che dovrebbe, chi lo ha comprato ha il diritto di decompilarlo per sistemarlo, anche senza chiedere il permesso a chi lo ha scritto.

La decisione sottolinea anche che non è necessario rispettare i requisiti dell’articolo 6 della stessa direttiva, che disciplina i casi di decompilazione per ottenere interoperabilità tra programmi diversi. Le due norme “have different purposes,” e nessuna disposizione della direttiva suggerisce che la decompilazione debba essere ammessa “only for ensuring interoperability”.

Attenzione però: non è un “liberi tutti”. La Corte elenca quattro condizioni da rispettare:

1. “Decompilation must be intended for error correction” e “necessary to allow the lawful acquirer to use the relevant software in accordance with its intended purpose.”
2. Deve rispettare “specific contractual provisions”, che possono regolare come avviene la correzione, ma non possono escluderla del tutto.
3. Il codice decompilato “must not be used for purposes other than error correction.”

Un altro passaggio importante riguarda il concetto stesso di “errore”. Secondo la Corte, si tratta di “defects preventing the use of software in accordance with its intended purpose.” Ma, a differenza dell’Avvocato Generale, la Corte non entra nel merito della definizione di errore. L’unico chiarimento è che la “technical obsolescence” non rientra nell’errore: aggiornare un software perché è diventato vecchio non è lecito senza il consenso del titolare dei diritti.

Infine, la Corte chiarisce un punto operativo fondamentale: l’acquirente non è obbligato a chiedere prima l’aiuto del titolare dei diritti. In parole loro: “lawful acquirers are not required to ask the rightholder to correct the errors, to request access to the program’s source code, or to bring legal proceedings seeking an order that the rightholder perform a particular act.”