Il codice è mio? Cinque domande prima di firmare

C'è una domanda che quasi nessuno fa prima di firmare un contratto di sviluppo, e che due anni dopo diventa la più importante di tutte: questo software di chi è?

Sembra una domanda con una risposta ovvia. L'ho pagato io, quindi è mio. La legge italiana non dà una risposta così secca, e nella pratica di tutti i giorni ancora meno. Vale la pena sapere cosa si sta comprando, perché la differenza si vede il giorno in cui vuoi cambiare fornitore.

Non serve un avvocato per fare queste domande. Servono cinque minuti e la voglia di farle prima invece che dopo.

"Tuo" può voler dire tre cose diverse

Quando ti dicono che il software sarà tuo, la frase può coprire tre situazioni molto distanti.

Ti cedono i diritti sul codice. È la versione piena. Il codice sorgente diventa tuo, puoi modificarlo, farlo modificare a chiunque, e chi lo ha scritto non può rivenderlo a qualcun altro. È quello che intendo io quando lo scrivo, ed è quello che va messo nero su bianco.

Ti danno una licenza d'uso. Il software resta di chi lo ha scritto e tu hai il diritto di usarlo. Può andare benissimo, ma è un'altra cosa e ha un altro prezzo. Il problema nasce quando la parola usata è "tuo" e la sostanza è questa.

Ti danno il codice ma non il resto. Questo caso sembra il primo ma non lo è. Ricevi i file sorgente, ma senza documentazione, senza le istruzioni per farlo partire e senza gli accessi ai servizi su cui gira. Formalmente hai tutto. In pratica nessun altro riesce a riprenderlo in mano senza rifarlo.

Le cinque domande da fare prima di firmare

Sono domande normali e si fanno prima, quando costano solo il fiato.

1. Il codice sorgente mi viene ceduto, e quando? La risposta buona è "al saldo" e sta scritta nel contratto. La cessione dei diritti va nominata esplicitamente. Per chi lavora da autonomo la legge dice che i diritti restano a chi scrive, salvo che quel software sia l'oggetto del contratto e venga pagato per quello. Cosa entra in quell'oggetto lo decide il contratto, e se non c'è scritto niente si discute.

2. In quale repository sta il codice, cioè in quale archivio, e intestato a chi? Il codice deve vivere in un posto che è tuo, dal primo giorno e non alla fine. Se sta su un account del fornitore e te lo manderanno "a lavoro finito", stai correndo un rischio che non serve correre.

3. Cosa mi consegnate oltre al codice? La lista minima: documentazione per far partire il progetto da zero, la struttura dei dati, i dati stessi, gli accessi ai servizi esterni, e gli account intestati alla tua azienda. Senza queste cose il codice è un mucchio di file.

4. Da quali servizi a pagamento dipende, e a nome di chi sono? Quasi ogni software oggi si appoggia a qualcosa: un servizio di posta, un database in cloud, un servizio di mappe, uno di pagamenti. Vanno elencati, con il costo, e gli account devono essere intestati a te. Se sono intestati al fornitore, il giorno che cambiate strada quel software si ferma.

5. Che licenze hanno le librerie usate? Un software è fatto anche di pezzi scritti da altri, ed è normale. Alcune licenze però impongono condizioni a chi le usa. Basta chiedere l'elenco e che sia scritto che sono compatibili con l'uso commerciale che ne farai.

Le due voci che si dimenticano sempre

Cosa succede se il rapporto finisce a metà. Non è una previsione, è una clausola. Serve stabilire che il lavoro fatto fino a quel punto, pagato fino a quel punto, resta tuo con quello che serve per riprenderlo. Senza quella riga si finisce a discutere in un momento in cui discutere costa caro.

Chi può riusare cosa. È normale che chi sviluppa riusi le proprie librerie e i propri modi di fare le cose da un progetto all'altro, e non è un problema. Il punto è che il tuo dominio, cioè la parte che descrive come lavora la tua azienda, non finisca nel prodotto che viene venduto al tuo concorrente. Anche questo si scrive in una riga.

Perché conviene anche a chi sviluppa

C'è un fraintendimento da sciogliere. Cedere il codice sembra una rinuncia, e invece è quello che rende il lavoro comprabile.

Un cliente che sa di poter cambiare fornitore compra più volentieri, perché sta rischiando meno. E un software scritto per essere ripreso da un altro è scritto meglio: ordinato, documentato, con i pezzi separati. Ed è parte di quello che paghi.

Stai per firmare e non sai cosa guardare? Queste cinque domande le puoi fare da solo, a chiunque. Se invece vuoi parlare di un progetto da fare, scrivimi. Rispondere e preparare un preventivo non si paga. → Parliamone

Domande frequenti

Il codice sorgente sviluppato su commissione è automaticamente mio? Non è scontato. Per chi lavora da autonomo la legge dice che i diritti restano a chi scrive, salvo che quel software sia l'oggetto del contratto e venga pagato per quello. Cosa comprende quell'oggetto, e cosa resta fuori, lo decide il contratto, quindi la cessione va scritta e va scritto cosa copre. È il motivo per cui vale la pena leggere quella riga prima di firmare invece che cercarla dopo.

Cosa devo farmi consegnare oltre al codice? La documentazione per far partire il progetto da zero, la struttura dei dati, i dati stessi, gli accessi ai servizi esterni e gli account intestati alla tua azienda.

Cosa succede se voglio cambiare fornitore? Se hai i diritti sul codice, il repository intestato a te e la documentazione, cambiare è un passaggio di consegne e basta. Se manca uno di questi tre pezzi, cambiare significa rifare, ed è lì che il costo esplode.

I servizi esterni a pagamento a chi devono essere intestati? A te. Gli account di posta, database, pagamenti e mappe vanno aperti a nome della tua azienda anche se li configura chi sviluppa. Così il giorno in cui il rapporto finisce il software continua a funzionare.

Chi mantiene il software se il codice è mio? Chi vuoi tu. Puoi tenere chi lo ha scritto con un accordo continuativo, portarlo dentro, o affidarlo a un altro fornitore. È proprio questa possibilità a rendere la proprietà del codice una cosa che vale.