Il codice di chi e'

5 minuti di lettura

Una domanda che quasi nessuno fa prima di firmare, e che dopo tre anni diventa l'unica che conta. Cosa guardare in un contratto di sviluppo software.

Nei primi incontri quasi nessuno chiede chi sara' il proprietario del codice. Si parla di funzioni, tempi e cifre, e la proprieta' sembra un dettaglio da avvocati. Poi passano tre anni, il rapporto col fornitore si raffredda o l'azienda cambia direzione, e diventa l'unica domanda che conta.

Le tre risposte possibili

Il codice e' del fornitore, tu hai una licenza d'uso. E' la formula piu' diffusa e la meno dichiarata. Funziona finche' il rapporto funziona. Quando finisce, ti resta un sistema che non puoi far toccare a nessun altro.

Il codice e' su una piattaforma. I dati sono tuoi ed esportabili, ma la logica no: automazioni, permessi, flussi e report vivono in una configurazione che non esce. Cambiare fornitore significa ricostruire tutto.

Il codice e' tuo. Sorgente e database sono tuoi, in un archivio a cui accedi. Se un giorno vuoi cambiare, ti porti via tutto e chiunque puo' riprendere il lavoro.

Perche' la terza non e' un favore

Puo' sembrare che un fornitore che cede il codice si stia togliendo la protezione da sotto i piedi. In realta' cambia il tipo di legame, e in meglio per entrambi.

Se il cliente e' bloccato, il fornitore non ha ragione di essere bravo: sa che tanto non se ne va. Se il cliente puo' andarsene domani mattina, l'unico modo di tenerlo e' fare un buon lavoro. Il rapporto smette di essere un vincolo e torna a essere una scelta, ripetuta ogni anno.

C'e' anche un effetto pratico: quando il codice e' del cliente si scrive in modo diverso. Si documenta, si tengono le convenzioni riconoscibili, si evitano le scorciatoie che solo chi le ha scritte capisce. Sapere che un giorno un altro sviluppatore aprira' quei file e' la migliore disciplina che esista.

Le quattro cose da guardare nel contratto

Titolarita' del codice sorgente

Deve dire esplicitamente che il sorgente sviluppato su commessa e' del committente. Attenzione alla differenza fra proprieta' e licenza d'uso perpetua e irrevocabile: la seconda suona rassicurante ma non ti lascia cedere il sistema, ne' modificarlo tramite terzi, se il contratto non lo prevede.

Dove sta il codice, adesso

Non alla fine del progetto: adesso. Un archivio a cui il committente ha accesso in lettura dal primo giorno. Se il codice sta solo sul computer di qualcuno, la proprieta' e' teorica.

Le librerie di terzi

Nessun progetto e' scritto interamente da zero. Il contratto deve distinguere fra il codice su commessa e i componenti di terzi, e dire con quale licenza girano. Un componente commerciale con licenza intestata al fornitore e' un vincolo, anche se il resto e' tuo.

Cosa succede alla fine

Va scritto prima, quando i rapporti sono buoni: consegna del sorgente aggiornato, dump del database, credenziali, documentazione, e un periodo di assistenza al fornitore che subentra. Se questa clausola manca, il passaggio si negozia nel momento peggiore possibile.

La verifica in un minuto

Se hai gia' un sistema in esercizio, c'e' una prova che vale piu' di qualunque lettura del contratto: chiedi al fornitore una copia del sorgente e un dump del database, oggi, senza spiegare perche'.

Se arriva entro un paio di giorni, sei a posto. Se arriva una domanda sul motivo della richiesta, hai gia' la risposta.

// quello che impariamo lavorando

Dalle nostre note.

Il messaggio che partirà Scegliete qualcosa qui sopra…
Apri WhatsApp col messaggio pronto

Oppure chiamateci: 351 240 7196 · [email protected]