Di chi è il codice di un software su misura

Il codice di un software su misura sviluppato da un fornitore esterno è di chi il contratto dice che è: la legge italiana tutela il software come opera dell'ingegno, e prevede espressamente che i diritti economici spettino al datore di lavoro per i programmi scritti dai suoi dipendenti, salvo patto contrario. Se lo sviluppo lo affidi a un'agenzia o a un professionista, per avere il codice conviene una clausola esplicita di cessione dei diritti, più tre cose pratiche: il repository intestato alla tua azienda, gli accessi a tuo nome e una consegna documentata. Le librerie di terzi restano dei loro autori, con le loro licenze.

Se stai per firmare un contratto di sviluppo, o hai scoperto che il software che usi ogni giorno vive su un account che non controlli, sai già che il problema non si vede finché non serve. Alla fine di questa guida avrai l'elenco di cosa scrivere nel contratto, cosa verificare durante il lavoro e cosa farti consegnare a fine progetto, con una variante per ogni situazione di partenza.

Cosa dice la legge, in breve

In Italia il software è tutelato dal diritto d'autore: la Legge 22 aprile 1941 n. 633 protegge i programmi per elaboratore come opere dell'ingegno. L'articolo 12-bis della stessa legge prevede che, per i programmi creati dal lavoratore dipendente nell'esecuzione delle sue mansioni o su istruzioni del datore di lavoro, i diritti di utilizzazione economica spettino al datore di lavoro, salvo patto contrario. Il testo della legge è consultabile su Normattiva.

Un'agenzia o un libero professionista non sono tuoi dipendenti. Quindi, per il software commissionato all'esterno, la domanda "di chi è il codice" trova risposta prima di tutto in ciò che hai firmato. Il resto di questa guida serve a fare in modo che quello che hai firmato coincida con quello che ti serve. Se ti interessa il quadro più ampio, cioè come si protegge un software aziendale anche con licenze, accordi di riservatezza e marchi, lo trovi nella guida sulla tutela del software aziendale.

Cosa serve prima di iniziare

• Il contratto o la proposta del fornitore, compresi allegati e condizioni generali: la clausola sul codice a volte non sta nel contratto ma in un documento richiamato in fondo.
• Il capitolato o la descrizione del progetto, perché definisce cosa è "scritto apposta per te" e cosa no. Se non l'hai ancora, la guida su come scrivere il capitolato di un software su misura ti aiuta a prepararlo.
• Un account aziendale su una piattaforma di gestione del codice, intestato a un indirizzo email dell'azienda e non a una persona.
• Una persona interna di riferimento, anche non tecnica, che custodisca accessi e credenziali e firmi le richieste.
• Un legale di fiducia a cui far leggere le clausole prima della firma.

Come assicurarti la proprietà del codice, passo per passo

1. Scrivi nel contratto chi ottiene cosa. Chiedi una clausola che dica in modo esplicito che i diritti di utilizzazione economica sul codice sviluppato per te sono ceduti alla tua azienda, compresa la possibilità di modificarlo, farlo modificare da terzi e trasferirlo. Alla stessa clausola va legato il momento del passaggio: alla consegna, al collaudo o al pagamento di ciascuna rata. Il risultato atteso è una frase che chiunque, anche fra cinque anni, legge nello stesso modo.

2. Elenca le eccezioni per nome. Se il fornitore usa una sua base tecnica, componenti già sviluppati per altri o un prodotto proprio, il contratto deve elencarli e dire con quale licenza li usi: durata, possibilità di modifica, cosa succede se il rapporto finisce. A questo punto saprai quale parte del software è tua e quale ti è data in uso.

3. Crea il repository a nome dell'azienda. Apri tu il repository sulla piattaforma che preferite e invita il fornitore come collaboratore, invece del contrario. Tu resti amministratore, lui lavora con i permessi che gli assegni. Da quel giorno vedrai ogni modifica con data e autore, e il codice non vive sul computer di nessuno.

4. Intesta all'azienda ogni accesso. Hosting, dominio, database, servizi di invio email, pagamenti, account degli store se c'è un'app: ciascuno va aperto con un'email aziendale e un metodo di pagamento aziendale, con il fornitore aggiunto come utente. Salva tutto in un archivio di password dell'azienda. Il risultato atteso è che tu possa entrare in ogni pannello senza chiedere a nessuno.

5. Chiedi l'elenco dei componenti di terzi con le loro licenze. Ogni software moderno usa librerie scritte da altri: è normale e utile. Fatti dare, e aggiornare a ogni rilascio importante, l'elenco delle librerie e dei servizi esterni con la licenza di ciascuno. Alcune licenze pongono condizioni se distribuisci il software o lo integri in un prodotto che vendi: meglio saperlo prima.

6. Definisci cosa vuol dire "consegna". Non basta "il codice sorgente". Scrivi che la consegna comprende il codice completo nel repository aziendale, le istruzioni per installarlo da zero, l'elenco delle configurazioni necessarie (senza le password scritte nel testo), lo schema del database, la procedura di rilascio e i test automatici, se previsti. A questo punto la consegna diventa verificabile, non una dichiarazione.

7. A fine progetto, fai la prova di ricostruzione. Chiedi che qualcuno diverso da chi ha scritto il codice, un tuo tecnico o un consulente esterno, provi a installare il software da zero seguendo solo la documentazione. Se ci riesce, hai davvero il software in mano. Se si ferma, sai esattamente cosa manca e lo chiedi mentre il progetto è ancora aperto.

8. Conserva la prova di cosa hai ricevuto. Annota la data della consegna, la versione del codice (il riferimento dell'ultima modifica nel repository) e l'elenco dei documenti ricevuti. È il fascicolo che ti servirà se un giorno cambierai fornitore o venderai l'azienda.

È il modo in cui impostiamo i progetti di sviluppo software su misura: niente licenze a canone, il codice è del cliente dal primo giorno e codice e dati restano sempre di sua proprietà.

Variante: il contratto è ancora da firmare

È il momento più semplice, perché tutto si può ancora chiedere senza attriti. Oltre ai passi sopra, verifica tre punti nel testo che ti arriva:

Se non hai ancora scelto a chi affidare il lavoro, la guida su come scegliere un'agenzia di sviluppo software è il passo che viene prima di questo: già al primo incontro si capisce chi accetta di parlarne apertamente.

Variante: il progetto è già in corso

Il contratto è firmato e il lavoro è partito. Qui non serve rinegoziare tutto: comincia dai passi che non richiedono di cambiare il contratto. Chiedi di spostare il repository su un account aziendale, o di aggiungerti come amministratore di quello esistente; intesta all'azienda gli accessi che ancora non lo sono; chiedi l'elenco dei componenti di terzi.

Poi rileggi la clausola sul codice. Se è vaga o manca, proponi un'integrazione scritta prima della consegna finale, quando entrambe le parti hanno interesse a chiudere bene. Un fornitore che lavora in modo trasparente di solito non ha difficoltà a mettere per iscritto ciò che in pratica fa già.

Variante: vuoi cambiare fornitore e scopri di non avere il codice

È la situazione più delicata, perché la scopri quando hai già deciso di andare altrove. L'ordine conta: prima verifichi cosa controlli già (hosting, dominio, database, account degli store), poi rileggi il contratto con un legale, e solo dopo annunci il cambio. Una richiesta scritta e precisa, con l'elenco di ciò che ti serve, funziona meglio di una richiesta generica di "tutto il codice".

Il percorso completo, dall'inventario degli accessi al passaggio di consegne graduale con il nuovo partner, è descritto nella guida su come cambiare fornitore software senza fermare il progetto.

Variante: il software poggia su una piattaforma dell'agenzia

Alcune agenzie costruiscono i progetti su una loro piattaforma o riusano componenti sviluppati negli anni. È un modo legittimo di lavorare e spesso accorcia i tempi. Cambia però cosa ricevi: la parte scritta per te può essere tua, mentre la base resta del fornitore e ti viene data in licenza.

In questo caso le domande da fare sono quattro. La licenza sulla base è perpetua o legata a un canone? Puoi far modificare il software a un altro fornitore? Cosa succede se l'agenzia chiude o smette di sviluppare la piattaforma? È previsto un deposito del codice presso un terzo, da cui puoi ritirarlo in casi precisi? Sono risposte da avere per iscritto prima della firma.

Per i gestionali la nostra scelta è un'altra: codice di proprietà, non licenza a canone, costruito su framework moderni e open source, così non c'è un vincolo a vita con noi e il codice puoi portarlo altrove, se vuoi. Come lavoriamo è spiegato nella pagina sul gestionale su misura.

Errori comuni

Confondere l'accesso con la proprietà. Poter entrare nel repository non vuol dire avere i diritti sul codice, e avere i diritti non vuol dire poterlo usare se non sai dov'è né come si installa. Servono entrambe le cose: la clausola nel contratto e il controllo pratico di repository e accessi.

Rimandare la questione alla consegna. Il momento in cui hai più forza per chiarire chi ottiene cosa è prima della firma. A progetto finito, o peggio a rapporto chiuso, la stessa richiesta diventa una trattativa.

Dimenticare quello che il codice usa per funzionare. Il codice da solo non basta: senza dominio, database, chiavi dei servizi esterni e procedura di rilascio non riparte. E dopo la consegna il software continua a cambiare: chi lo mantiene deve lavorare sullo stesso repository aziendale, come descritto nella guida sulla manutenzione del software aziendale. Anche le credenziali vanno trattate con le precauzioni descritte nella guida sulla sicurezza del software su misura.

Chi siamo

Obly è un'agenzia di sviluppo software su misura con sede a Casale Monferrato (AL) che progetta web app, gestionali e integrazioni fra i sistemi che un'azienda usa già. Nei nostri progetti il codice è del cliente dal primo giorno, senza licenze a canone, e codice e dati restano sempre di sua proprietà.

Queste sono indicazioni generali e non sostituiscono un parere legale: per il tuo contratto fatti assistere da un legale di fiducia.

Quanto tempo serve e il passo successivo

Su un contratto ancora da firmare, mettere a posto clausola, repository e accessi richiede pochi giorni, gran parte dei quali per la lettura del legale. Su un progetto in corso conta quanto collabora il fornitore: con un fornitore disponibile bastano una o due settimane, mentre la prova di ricostruzione a fine progetto si misura in giorni di lavoro tecnico.

Ora che sai cosa chiedere, il passo successivo è prendere il contratto che hai sul tavolo e confrontarlo con la tabella della prima variante. Se vuoi parlarne per il tuo progetto, parti dalla pagina sullo sviluppo software su misura oppure scrivici dai contatti, raccontandoci a che punto sei e chi ha oggi in mano il codice.