Software e codice sorgente

È l'ambito in cui la mia esperienza pesa di più, perché per vent’anni il software l'ho scritto, l'ho fatto scrivere e l'ho mandato in produzione. Il contenzioso su una fornitura si decide su fatti che ho visto accadere molte volte.

Le controversie ricorrenti

Inadempimento e difformità

Il committente sostiene che il software non fa quello che doveva fare; il fornitore sostiene che fa esattamente quello che era stato chiesto. Nella quasi totalità dei casi la vera controversia non è sul codice ma su che cosa fosse stato pattuito, e la risposta va cercata nella documentazione contrattuale, nelle specifiche, nei verbali di collaudo e — spesso decisiva — nella corrispondenza fra le parti durante lo sviluppo, dove i cambi di requisito compaiono senza essere mai formalizzati.

Sul piano tecnico si accerta che cosa il programma consegnato faccia realmente: lo si installa in un ambiente controllato, si eseguono i casi previsti dalle specifiche e si documenta l'esito di ciascuno. È un lavoro meno spettacolare di quanto ci si aspetti, e quasi sempre risolutivo.

Proprietà del codice e riuso

Chi possiede il codice sviluppato su commessa dipende dal contratto, e in mancanza di clausole chiare il quadro di partenza è quello del diritto d'autore: il programma è opera dell'ingegno e i diritti nascono in capo all'autore, con la regola diversa prevista per le opere create dal lavoratore dipendente nell'esecuzione delle proprie mansioni. La legge sul diritto d'autore, nella parte dedicata ai programmi per elaboratore, è il riferimento.

Il contributo tecnico consiste nello stabilire di quale codice si stia parlando: quali porzioni siano state effettivamente scritte per quella commessa, quali provengano da librerie di terzi, quali siano state riusate da lavori precedenti. Il confronto fra basi di codice si fa con misure di similarità e con l'esame della cronologia del sistema di versionamento, che registra chi ha scritto che cosa e quando con un dettaglio che nessuna dichiarazione di parte può eguagliare.

Licenze open source

Un capitolo che compare sempre più spesso. Quasi ogni software contiene componenti di terzi rilasciati con licenze che impongono obblighi: attribuzione, conservazione delle note di copyright e, per alcune licenze, l'obbligo di rendere disponibile il codice sorgente dell'opera derivata. Un prodotto che incorpora componenti di quel tipo senza rispettarne le condizioni espone il committente a un rischio che spesso nessuno gli ha mai illustrato. L'accertamento consiste nel censire i componenti e le rispettive licenze e nel verificarne la compatibilità con il modello di distribuzione.

Sottrazione di codice e concorrenza sleale

Un ex collaboratore avvia un'attività concorrente con un prodotto molto simile. La domanda tecnica è se vi sia derivazione. Si risponde confrontando le basi di codice — non solo il testo, che è facile da riscrivere, ma la struttura, i nomi interni, gli errori ripetuti, i commenti, le scelte arbitrarie che due autori indipendenti non compierebbero mai allo stesso modo — e ricostruendo, dai registri di accesso e dalla cronologia dei repository, che cosa sia stato copiato e quando.

Il metodo

• Ambiente ricostruito. Il software si esamina eseguendolo in un ambiente isolato che riproduca quello di riferimento, non sui sistemi di produzione di una delle parti.
• Cronologia, non dichiarazioni. I sistemi di versionamento registrano autore, data e contenuto di ogni modifica. Sono manipolabili, ma la manipolazione lascia incoerenze rilevabili.
• Riproducibilità. Ogni prova eseguita è descritta in modo che il consulente della controparte possa ripeterla e ottenere lo stesso risultato. Quando serve, allego gli script che ho usato.