Che cosa Le appartiene quando il software personalizzato è pronto: codice, dati e dipendenza dallo sviluppatore

Il sistema è stato consegnato, la fattura è pagata, e dopo sei mesi l’azienda decide di cambiare sviluppatore, e proprio in quel momento si pone la domanda che finora a nessuno pareva urgente: a chi appartiene ciò per cui si è pagato. In Italia la risposta sorprende quasi tutti quelli che la sentono per la prima volta, perché il pagamento dello sviluppo, da solo, non dà al committente il diritto d’autore sul programma per elaboratore realizzato, e non è un vezzo giuridico, ma la regola che opera ogni volta che nel contratto non è scritto nient’altro.

Questo articolo riguarda che cosa resta nelle Sue mani dopo la consegna, e non è la stessa domanda che abbiamo già esaminato confrontando un prodotto pronto con il software su misura. Là si trattava di che cosa scegliere; qui si tratta di che cosa tiene in mano, quando la scelta è già fatta e il sistema funziona. La risposta si divide in tre parti: il codice e i diritti su di esso, i dati insieme al luogo in cui stanno, e la dipendenza dalle persone che conoscono il sistema.

L’autore è una persona; l’azienda, solo nei casi previsti

Nel diritto d’autore italiano l’autore è la persona fisica il cui atto creativo ha prodotto l’opera, e autori sono i programmatori, i designer e gli autori dei testi che hanno lavorato al sistema. Un’azienda non è l’autore per il solo fatto di pagare, ma la legge stessa nomina i casi: l’articolo 7 considera autore dell’opera collettiva chi organizza e dirige la creazione, e l’articolo 11 attribuisce il diritto d’autore allo Stato e agli enti pubblici culturali ivi indicati sulle opere create e pubblicate sotto il loro nome. I programmi per elaboratore sono protetti come opere letterarie, come nella direttiva 2009/24/CE dell’Unione europea, e il diritto d’autore sorge nel momento in cui l’opera è creata, senza registrazione, senza contrassegno e indipendentemente dal fatto che l’opera sia finita.

Il diritto d’autore si divide in due parti, che la legge italiana chiama diritti morali e diritti patrimoniali di utilizzazione, e in pratica è la distinzione più importante di tutto questo tema, perché soltanto una delle due può arrivare all’azienda. La parte patrimoniale è quella che si può cedere, e nel caso di un programma per elaboratore consente di distribuirlo, di renderlo disponibile, di locarlo, di riprodurlo, e anche di tradurlo, adattarlo o trasformarlo altrimenti e di riprodurre i risultati della trasformazione. La parte morale resta all’autore per tutta la vita e non si cede a nessuno, ed è proprio per questo che nessun contratto può scrivere che l’azienda diventa l’autore.

C’è un altro confine, che si nota di rado, e può rivelarsi costoso. L’articolo 12-bis della legge 22 aprile 1941, n. 633, che porta al datore di lavoro il diritto esclusivo di utilizzazione economica, parla del programma per elaboratore — e della banca di dati — creato dal lavoratore dipendente; per tutto il resto di ciò che il progetto produce, cioè grafica, documentazione, testi e istruzioni, non esiste lo stesso passaggio automatico. In pratica, nello stesso progetto due cose create possono avere due titolari diversi, e un contratto che parla soltanto del software può lasciare fuori la grafica.

Da qui le prime conseguenze pratiche, che conviene capire prima di tutto il resto: quando un’azienda commissiona un sistema a un’agenzia, la catena dei diritti è lunga almeno due anelli, perché prima i programmatori sono gli autori, poi l’agenzia ha o non ha ottenuto da loro la parte patrimoniale, e soltanto allora l’agenzia può cedere qualcosa a Lei. Se manca un anello, l’agenzia promette più di quanto le appartiene, e lo si nota soltanto quando qualcuno comincia a verificare.

Dipendente e commissione sono due regole diverse in mancanza di patto

Qui sta il nucleo dell’articolo, ed è il punto in cui l’intuizione va dalla parte sbagliata. L’articolo 12-bis della legge 22 aprile 1941, n. 633, dispone che, salvo patto contrario, il datore di lavoro è titolare del diritto esclusivo di utilizzazione economica del programma per elaboratore creato dal lavoratore dipendente nell’esecuzione delle sue mansioni o su istruzioni impartite dallo stesso datore di lavoro. È la risposta italiana all’articolo 2, paragrafo 3, della direttiva 2009/24/CE, e riguarda soltanto il lavoro subordinato e i programmi, insieme alle banche di dati.

Nel caso della commissione la regola è l’inversa, ed è proprio per questo che i due casi non vanno confusi: il contratto di commissione obbliga l’autore a eseguire l’opera ordinata e a consegnarla al committente perché la usi, ma da solo non dice che la parte patrimoniale passi al committente. Il contratto d’appalto, all’articolo 1655 del codice civile, sul diritto d’autore non dice nulla, perché regola l’esecuzione e la consegna del risultato, non la circolazione dei diritti.

Se si mettono insieme, ne esce la situazione in cui finisce un’azienda tipica, spesso senza saperlo: il cliente commissiona il sistema all’agenzia; i programmatori sono dipendenti dell’agenzia, quindi l’articolo 12-bis porta la parte patrimoniale all’agenzia; il contratto tra cliente e agenzia è un contratto d’appalto, che non la sposta oltre. Il risultato è che il cliente ha pagato il risultato e ha ricevuto il risultato, ma la parte patrimoniale è restata all’agenzia, e l’unica cosa che il cliente ha è una licenza d’autore implicita, dal contenuto incerto, a usare il sistema per lo scopo per cui è stato commissionato.

L’equivoco va detto per esteso: è infondato il pensiero che i diritti sul programma appartengano a chi ha commissionato e pagato lo sviluppo, e la legge sul diritto d’autore non prevede un passaggio automatico al committente. Il contenuto di una licenza d’autore implicita resta incerto, e conviene leggerlo insieme al testo della legge, che in questo caso conferma proprio questo schema: l’articolo 12-bis riguarda i dipendenti, e il contratto d’appalto non sposta i diritti patrimoniali.

Ricevere i file non è ricevere i diritti

Il secondo assunto che non regge è che ricevere il codice decida qualcosa, ma l’articolo 109 della legge 22 aprile 1941, n. 633, dispone che la cessione di uno o più esemplari dell’opera non importa, salvo patto contrario, la trasmissione dei diritti di utilizzazione. In pratica, un archivio con tutto il codice sorgente, l’accesso al repository e persino la documentazione completa non sono ancora il diritto di usare quel codice, di trasformarlo e di passarlo a un altro sviluppatore.

Funziona anche al contrario, e questo lato è meno noto, perché un’azienda può aver ottenuto i diritti patrimoniali con un contratto ben scritto e non aver comunque ricevuto il codice sorgente, se nel contratto non era scritto a parte l’obbligo di consegnarlo. Un’autorizzazione senza il file è inutilizzabile quanto un file senza autorizzazione, quindi nel contratto servono entrambi, e sono due punti autonomi, non un punto solo che include l’altro da sé.

Quando i diritti vengono ceduti per bene, la legge chiede una certa precisione, e non è una formalità: i diritti patrimoniali si possono cedere o licenziare, e il contratto può indicare territorio e durata. In Italia non esiste una regola per cui, se il territorio manca, la cessione si considera avvenuta soltanto nello Stato in cui il contratto è stato concluso; quel silenzio va riempito nel contratto, e per un’azienda che opera in più Paesi, o che pensa di operarvi, è un motivo diretto per scrivere il territorio. Conviene inoltre nominare i diritti di utilizzazione che si intendono trasferire, perché una formula su un solo modo d’uso non apre gli altri.

C’è un’altra sorpresa che aspetta l’azienda che vive su una licenza implicita e non l’ha mai messa per iscritto. In Italia non esiste una norma che consenta di recedere da una licenza d’autore a tempo indeterminato con preavviso di sei mesi, né che dichiari nulla la rinuncia a quel diritto. Resta il fatto che un’azienda la cui unica base per usare il sistema è un accordo non scritto vive su una licenza d’autore implicita, dal contenuto incerto, e da quella incertezza non si esce se non scrivendo.

I diritti morali e che cosa, da soli, non fermano

Nella parte morale rientrano la paternità, il nome e l’integrità dell’opera, e restano all’autore, perché questi elementi non si cedono a un’altra persona. All’azienda che ha commissionato il sistema, all’inizio, questo suona minaccioso, perché nasce l’impressione che un ex sviluppatore possa, a un certo punto, chiedere di fermare il sistema.

In pratica non è una via affidabile per fermarlo, e il motivo non è un emendamento italiano del 2023: in Italia non è stata introdotta una norma che, sui diritti morali, tolga all’autore del programma il potere di opporsi alla trasformazione, all’alterazione o all’integrazione, salvo il pregiudizio all’onore e alla reputazione. Trasformare e adattare il programma è un diritto patrimoniale di utilizzazione; i diritti morali restano. Un ex programmatore non ferma la manutenzione ordinaria né una riscrittura in quanto titolare di quei diritti patrimoniali, se sono passati al datore di lavoro ai sensi dell’articolo 12-bis.

Nella trasposizione del 2021 c’è un’altra norma favorevole all’azienda, e conviene conoscerla, perché altrimenti la si può aspettare dalla parte sbagliata. L’articolo 110-quater della legge 22 aprile 1941, n. 633, dal 7 giugno 2022, dà all’autore il diritto di ricevere informazioni sullo sfruttamento, e l’articolo 110-quinquies una remunerazione ulteriore, adeguata ed equa, se il compenso pattuito è sproporzionatamente basso. In quei due articoli l’esclusione dei programmi per elaboratore non è scritta: l’articolo 23, paragrafo 2, della direttiva (UE) 2019/790 non è stato riportato lì. L’articolo 114-bis, comma 3, della stessa legge dispone però che gli articoli 110-quater e 110-quinquies non si applicano agli autori di programmi per elaboratore. Un programmatore che ritenga il sistema più prezioso di quanto le parti si aspettassero non può, su questo fondamento, chiedere un compenso ulteriore.

Resta la possibilità di essere nominato come autore e la protezione contro un uso dell’opera che pregiudichi l’onore e la reputazione, e questo è un rischio sensibilmente minore, con cui si può convivere. Non vanno confuse due cose: la trasformazione come questione di diritti morali non è, in Italia, spenta da una norma del 2023, ma la trasformazione come parte patrimoniale continua a richiedere l’autorizzazione del titolare, quindi se la parte patrimoniale è restata all’agenzia, per rifare il sistema serve ancora il suo consenso.

Che cosa dà la legge anche senza un buon contratto

Anche all’azienda che non ha formalizzato nulla, la legge dà alcune possibilità, e conviene sapere quali di esse il contratto può togliere e quali no. L’articolo 64-ter, comma 1, della legge 22 aprile 1941, n. 633, consente al legittimo acquirente, salvo patto contrario, le attività di riproduzione e di traduzione necessarie per l’uso del programma conformemente alla sua destinazione, inclusa la correzione degli errori; questa facoltà opera soltanto se il contratto non dispone altrimenti, quindi il contratto può toglierla, e molti contratti lo fanno.

Fare una copia di riserva è un caso diverso, ed è l’unico di questi casi che il contratto non può togliere, perché l’articolo 64-ter, comma 2, dispone che non può essere impedito per contratto, a chi ha il diritto di usare una copia del programma, di effettuare una copia di riserva qualora tale copia sia necessaria per l’uso, e ciò corrisponde all’articolo 5, paragrafo 2, della direttiva 2009/24/CE. L’articolo 8 della direttiva dispone inoltre che sono nulle le clausole contrattuali in contrasto con l’articolo 6 o con le eccezioni di cui all’articolo 5, paragrafi 2 e 3.

Conviene essere precisi, perché la differenza è sottile e facile da esagerare: la legge italiana, per la copia di riserva, usa la formula per cui il divieto non può essere pattuito, e nell’articolo sulla decompilazione c’è una frase distinta che dichiara nulle le clausole contrarie. L’ultima frase dell’articolo 64-ter e l’articolo 64-quater, comma 3, recepiscono l’articolo 8 della direttiva; è quindi corretto scrivere che la copia di riserva non si può togliere nel contratto e che, in Italia, sono nulle anche le clausole in contrasto con l’eccezione di decompilazione.

La decompilazione, a sua volta, è consentita in modo stretto e a condizioni: si può fare per conseguire l’interoperabilità di un programma creato autonomamente, se le informazioni non sono già facilmente e rapidamente accessibili, la compie chi ha il diritto di usare una copia, e l’attività è limitata alle parti necessarie per l’interoperabilità. Le informazioni ottenute non si possono usare per altri fini né per creare un programma sostanzialmente simile, e questa via d’uscita è utile ma stretta, e nessuna azienda vuole che sia l’unica.

Nel sistema c’è molto codice che non sarà mai Suo

Un sistema su misura quasi mai è soltanto il codice che ha scritto lo sviluppatore, perché gran parte del volume viene da librerie e da un framework che esistevano già. Quel codice non diventa mai Sua proprietà, in nessun contratto, perché Lei riceve una licenza dai suoi autori, e questa differenza conta proprio quando qualcuno promette di cedere tutti i diritti sul sistema.

Le licenze permissive non creano un problema, perché chiedono poco e non limitano il modo in cui il sistema finito si può usare in un’attività commerciale. La licenza MIT consente di usare, copiare, modificare, unire, pubblicare, distribuire e vendere, purché si conservino l’avviso di diritto d’autore e la licenza stessa, e il software è consegnato così com’è, senza garanzie, mentre la licenza Apache 2.0 vi aggiunge una licenza di brevetto espressa e chiede di segnare le modifiche apportate. Entrambe sono compatibili con un sistema commerciale chiuso, la maggior parte dei framework moderni è una delle due, ed è proprio per questo che questa parte del sistema di solito non chiede alcuna trattativa.

Le licenze copyleft chiedono attenzione, non panico, ed è proprio qui che più spesso si raccontano mezze verità, sebbene la Free Software Foundation, nella propria pagina di domande sulla GPL, scriva con chiarezza che un’azienda che fa girare un programma GPL modificato sul proprio sito web non è obbligata a pubblicare il codice sorgente modificato, perché l’obbligo copyleft scatta quando si consegnano copie ad altri, non quando si usa il programma in casa. Fare e usare più copie all’interno di una stessa organizzazione non è distribuzione, sebbene consegnare copie ad altre organizzazioni, compresi gli appaltatori per un uso fuori dall’azienda, lo sia già.

L’eccezione è la licenza Affero, ed è proprio il suo articolo 13 — la clausola di interazione tramite rete (AGPL §13) — a sorprendere, perché se Lei modifica il programma e la versione modificata consente agli utenti di comunicarvi a distanza su una rete di calcolatori, allora a quegli utenti va offerta la possibilità di ricevere il relativo codice sorgente. Le condizioni sono due e servono entrambe: la modifica e l’interazione remota degli utenti, quindi non è corretto dire che qualsiasi uso di una licenza Affero richiede la pubblicazione del codice sorgente, e non è corretto dire che una sola libreria di questo tipo assoggetta automaticamente l’intero sistema, perché dipende da come i componenti sono collegati.

Il deposito presso un terzo, e che cosa dà davvero

Il deposito del codice sorgente è un accordo a tre, in cui lo sviluppatore consegna il codice a un depositario neutrale, e il depositario lo rilascia al committente soltanto se si verifica il caso descritto nel contratto, e i casi tipici sono il fallimento, la cessazione dell’attività o un inadempimento sostanziale degli obblighi di manutenzione dopo un avviso. In Italia non esiste una legge che fissi o elenchi questi casi, quindi tutto ciò che opera è ciò che le parti hanno scritto, e per questo il contratto di deposito va letto con la stessa attenzione del contratto di sviluppo.

Il deposito dà esattamente ciò che è stato depositato, e soltanto quando si verifica ciò che è descritto, ma da solo non cede il diritto d’autore, perché anche qui vale l’articolo 109, e non insegna a far girare il sistema. La società NCC Group, che vende questo servizio da decenni, lo ammette nei propri materiali: avere il codice sorgente in cassaforte è una cosa, saperlo compilare è un’altra, ed è proprio per questo che la stessa società vende anche la verifica del contenuto depositato. È la valutazione di una parte interessata, ma è un’ammissione sul punto debole del proprio servizio principale, e per questo è utilizzabile.

I sistemi moderni hanno anche un secondo limite, che con il lato giuridico non c’entra affatto: se il sistema gira come servizio sull’infrastruttura dello sviluppatore, allora il codice sorgente senza l’ambiente di esecuzione, la configurazione e i dati risolve la parte minore del problema, perché al destinatario resta un archivio, non un sistema che funziona. Nella pratica si chiude questo vuoto integrando il deposito con un accordo su chi riprende l’ambiente e che cosa succede se le fatture di hosting restano insolute, e proprio questi punti di solito non compaiono nei moduli standard di deposito.

C’è anche un ostacolo giuridico che sta nel fallimento più che nel diritto d’autore: nella procedura concorsuale il materiale depositato e la sua restituzione possono entrare in conflitto con il regime della massa, proprio nel caso per cui il deposito si compra più spesso. La conclusione pratica non è rinunciare al deposito, ma non considerarlo un sostituto di una cessione scritta dei diritti e di una consegna regolare del codice sorgente.

Dove sta il repository e dove stanno i dati

La domanda su dove stanno il codice e i dati decide più della domanda su a chi appartengono, perché i diritti senza accesso sono un problema lento. La documentazione di GitHub descrive con chiarezza che un’organizzazione è un account condiviso a cui appartengono i repository, che non ci si entra come organizzazione, perché le persone accedono con account personali, e che i proprietari dell’organizzazione hanno sempre accesso a tutti i repository; un repository può appartenere a un account personale o a un’organizzazione, e questa scelta conta più di quanto sembra.

Se il repository appartiene all’account personale dello sviluppatore, l’accesso del cliente è soltanto un accesso da collaboratore, che il titolare dell’account può revocare in qualsiasi momento, e andandosene dal progetto porta via anche l’indirizzo stesso. Se il repository appartiene all’organizzazione del cliente, in cui lo sviluppatore è stato invitato come membro, andarsene significa togliere un accesso e nient’altro, ed è una delle rare cose in questo articolo che si possono sistemare in un giorno solo e senza un avvocato.

I dati sono una questione a parte, e lì non si parla più di diritto d’autore: se lo sviluppatore tratta dati personali per Suo conto — cioè fa girare l’ambiente di produzione, accede a dati di clienti o di dipendenti o fa i backup — allora Lei è il titolare del trattamento e lo sviluppatore è il responsabile del trattamento ai sensi del regolamento generale sulla protezione dei dati. L’articolo 28 del regolamento richiede un contratto scritto con punti precisi: oggetto e durata del trattamento, natura e finalità, tipi di dati e categorie di interessati, nonché i diritti e gli obblighi del titolare.

Il puro lavoro di scrittura del codice senza accesso a dati personali non fa scattare l’articolo 28, quindi non ogni contratto di sviluppo ha bisogno di un contratto con il responsabile del trattamento. Il confine è semplice e verificabile: se lo sviluppatore può vedere dati reali dei clienti, allora serve, ma se lo sviluppatore lavora soltanto con dati di test e non vede l’ambiente di produzione, allora non serve, e questo di per sé è un argomento a favore di un ambiente di test separato.

I vantaggi del software personalizzato: che cosa ottiene e che cosa si assume

La logica di questo articolo finora è stata unilaterale, quindi è onesto dire anche l’altra faccia: il controllo pieno su un sistema su misura non è soltanto un vantaggio, ma anche un insieme di obblighi che non spariscono. Per un software già pronto, manutenzione, patch di sicurezza e compatibilità con i nuovi ambienti li assicura il produttore, e questo è compreso nel canone di abbonamento; per un sistema su misura li assicura il titolare, cioè Lei, ed è una spesa diretta che compare ogni anno indipendentemente dal fatto che nel sistema cambi qualcosa.

La seconda cosa che si assume è l’invecchiamento del sistema, che si accumula in silenzio e non si manifesta in alcun modo finché qualcuno non lo cerca. Il sistema poggia su versioni del linguaggio e del framework per le quali i produttori fissano termini di supporto, e dopo la fine di quei termini le nuove vulnerabilità non vengono più corrette, sebbene il sistema continui a funzionare esattamente come prima e nessuna schermata avverta. Non è un divieto di far girare un sistema invecchiato, ma è il momento in cui il rischio passa al titolare, e le date concrete per PHP e Laravel le abbiamo raccolte nell’articolo su che cosa implica scegliere PHP e Laravel, quindi qui non le ripetiamo.

Il terzo è il mercato, e per una piattaforma già pronta uno specialista si trova con relativa facilità, perché li formano e sono in più; un sistema su misura lo conoscono soltanto quelli che l’hanno costruito, e a un nuovo sviluppatore va dato tempo per conoscerlo prima che possa cambiare qualcosa in sicurezza. Questo non significa che il subentro sia impossibile, ma significa che costa, e questo costo compare proprio nel momento in cui il rapporto con lo sviluppatore precedente è già finito.

Proprio per questo la domanda su che cosa Le appartiene non è una formalità giuridica, ma la domanda su quanto costerà la scelta successiva. Un’azienda con una cessione scritta, il codice sorgente nel proprio repository e un elenco dei componenti usati può cercare un nuovo sviluppatore in una settimana; un’azienda senza tutto questo prima scopre che cosa le è lecito fare, e soltanto dopo comincia a cercare, ed è la differenza tra una trattativa da una posizione e una trattativa da un bisogno.

Che cosa scrivere nel contratto, finché si può ancora

Tutte le sezioni precedenti portano a un piccolo insieme di punti che conviene scrivere nel contratto prima che il lavoro inizi, perché dopo la consegna la posizione negoziale è molto più debole. Il primo è la cessione scritta dei diritti patrimoniali, nominando quali diritti passano, in quale territorio e per quale durata, perché se il territorio non è indicato il contratto resta muto su un punto che va scritto, non lasciato al silenzio. Il secondo è l’attestazione che l’agenzia li ha ottenuti dai propri dipendenti e subappaltatori, perché senza questo anello la cessione stessa può essere vuota.

Il terzo è la consegna regolare del codice sorgente e di tutto ciò che serve per compilarlo, non una consegna unica a fine progetto, e il quarto è che il repository stia nell’account della Sua organizzazione già dal primo giorno. Il quinto è l’elenco dei componenti open source con le relative licenze, perché senza questo elenco nessuno saprà più tardi che cosa c’è nel sistema e a quali condizioni; il sesto è il contratto con il responsabile del trattamento, se lo sviluppatore vedrà dati reali, e il settimo è l’accordo su che cosa succede di ambienti, chiavi e accessi alla fine della collaborazione.

Nessuno di questi punti chiede un testo lungo, nessuno è in contrasto con una buona collaborazione, e nessuno sviluppatore onesto vi si oppone, perché mettono per iscritto esattamente ciò che entrambe le parti pensano comunque. L’unica cosa che cambiano è che l’accordo non dipende più dal fatto che, fra tre anni, quelle persone lavorino ancora nella stessa azienda e che qualcuno ricordi ciò che allora fu detto a voce. Questi punti conviene chiederli a qualsiasi sviluppatore, anche a noi, e scriverli nel contratto prima che il lavoro inizi. La nostra pagina di sviluppo di sistemi aziendali su misura oggi promette di consegnare a fine lavoro il codice sorgente, la documentazione e la configurazione dell’infrastruttura, ed è proprio per questo che il terzo punto di questo elenco, cioè la consegna regolare in corso d’opera, conviene discuterlo a parte, non dare per scontato. Se vuole che esaminiamo un contratto già esistente, Ci scriva.