Indice
Perché il codice sorgente va protetto
Il codice sorgente è il testo scritto da uno sviluppatore in un linguaggio di programmazione, il progetto originale da cui nasce ogni software, sito o applicazione. Chi lo possiede può modificarlo, aggiornarlo o farlo evolvere: per questo, nella maggior parte dei rapporti di sviluppo, il programmatore consegna al cliente solo il programma funzionante, non il codice che lo genera — a meno che non sia stato pattuito diversamente nel contratto.
Questo rende il codice sorgente uno degli asset più preziosi di uno sviluppatore o di una software house: rappresenta il vero valore intellettuale del lavoro, molto più dell'eseguibile che ne deriva.
Deposito e source code escrow: due strumenti diversi
Qui è facile fare confusione, quindi ti chiarisco subito la differenza.
Il source code escrow è un contratto trilaterale tra sviluppatore, cliente e un soggetto terzo imparziale (spesso un notaio), pensato per garantire la continuità del cliente: se lo sviluppatore non è più in grado di fornire assistenza — fallimento, cessazione dell'attività — il cliente può ottenere dal terzo depositario una copia del codice sorgente. È uno strumento di garanzia contrattuale, orientato a chi riceve il software in licenza.
Il deposito con finalità di prova della paternità, di cui parliamo in questo articolo, ha uno scopo diverso: non riguarda la continuità del servizio verso un cliente, ma la tua capacità di dimostrare, verso chiunque, in qualsiasi momento, che una determinata versione del codice è opera tua, in una data precisa. È lo strumento che ti serve se temi che qualcuno possa copiare, rivendicare o contestare la paternità del tuo lavoro.
Come dimostrare la paternità del tuo codice
Il principio è lo stesso che regge ogni prova di anteriorità (di cui parliamo più in generale in a cosa serve la prova di anteriorità di un'opera): serve un elemento verificabile che colleghi il tuo codice a un momento preciso nel tempo, con un metodo che nessuna delle parti possa aver manipolato dopo i fatti.
Le opzioni disponibili includono:
- SIAE, tramite il Pubblico Registro per il Software, una via tradizionale, pensata soprattutto per opere già strutturate come prodotto finito.
- Notaio, per un deposito formale con piena validità legale, ma con costi non sempre proporzionati a un singolo repository o a un progetto in evoluzione continua.
- Certificazione digitale con data certa, che attribuisce al codice (o meglio, alla sua impronta digitale, l'hash) una data e un'ora verificabili — un metodo che approfondiamo nella nostra guida data certa: cos'è e come attribuirla a un documento.
Cosa depositare, in pratica
Un errore comune è pensare di dover depositare l'intero repository ogni volta che cambia qualcosa. Nella pratica, ha senso certificare:
- una versione stabile del codice, in corrispondenza di milestone significative del progetto;
- la documentazione tecnica che accompagna il software, utile a dimostrare non solo il codice ma anche il metodo e le scelte progettuali;
- ogni versione che condividi con terzi — un potenziale cliente, un investitore, un collaboratore — prima di farlo, non dopo.
Concludendo, depositare il codice sorgente per proteggerne la paternità è un'operazione diversa dal source code escrow, anche se i due strumenti vengono spesso confusi: uno tutela il cliente dalla scomparsa dello sviluppatore, l'altro tutela te dalla contestazione della tua stessa opera.
Per la maggior parte degli sviluppatori indipendenti e delle piccole software house, la seconda è la protezione più urgente da mettere in pratica.
Proteggi il tuo repository con IÈUMÌ®.
FAQ
Il source code escrow protegge anche la paternità del codice?
Non è il suo scopo principale. In sintesi:
- l'escrow garantisce al cliente la continuità del servizio in caso di inadempimento dello sviluppatore;
- non certifica automaticamente quando il codice è stato scritto, né impedisce contestazioni sulla paternità;
- per dimostrare la paternità serve uno strumento specifico di prova con data certa, distinto dall'escrow.
Con quale frequenza conviene certificare il proprio codice?
Non esiste una regola fissa, ma un buon criterio pratico è:
- ogni volta che raggiungi una versione stabile o una milestone importante del progetto;
- prima di condividere il codice con un cliente, un partner o un investitore;
- quando introduci una funzionalità che rappresenta un vantaggio competitivo da proteggere.