Codice sorgente, dominio e account: cosa deve restare tuo quando commissioni un software
Hai pagato per un sito, un'app o un gestionale, ma è davvero tuo? Codice sorgente, dominio, hosting e account degli store: cosa deve essere intestato alla tua azienda e le domande da fare prima di firmare.
C'è uno scenario che si ripete più spesso di quanto si pensi. Un'azienda commissiona un sito, un'app o un gestionale. Il progetto funziona, passano un paio d'anni, poi il rapporto con il fornitore si interrompe: cambia lavoro, smette di rispondere, oppure semplicemente si decide di cambiare.
È in quel momento che si scopre che il dominio è registrato a suo nome. Che l'app è pubblicata sul suo account sviluppatore. Che il server è pagato con la sua carta e il codice sta su un computer a cui nessun altro ha accesso.
Nessuno aveva cattive intenzioni. Semplicemente, all'inizio, era più comodo così. Questo articolo serve a evitare che quella comodità diventi un problema.
Pagare un software non significa possederlo
È la cosa che sorprende di più chi commissiona un software per la prima volta: aver pagato lo sviluppo non significa, automaticamente, esserne proprietari.
In Italia il software è tutelato dal diritto d'autore, e i diritti nascono in capo a chi lo scrive. Il passaggio automatico all'azienda vale per i dipendenti; quando invece il software è commissionato a un fornitore esterno, conta quello che c'è scritto nel contratto. Se il contratto non dice nulla, il rischio concreto è ritrovarsi con una semplice licenza d'uso invece che con la proprietà.
Non sono un avvocato, e per il contratto vale sempre la pena farsi seguire da un legale. Ma la domanda da porre è semplice: il contratto prevede la cessione dei diritti sul software, o solo una licenza d'uso? Entrambe le risposte possono andare bene, purché siano chiare prima di firmare.
Le cinque cose che devono essere intestate a te
Il dominio. Registrato a nome della tua azienda, con le credenziali del pannello del registrar in mano tua. Il dominio è l'indirizzo con cui i clienti ti trovano e su cui girano le tue email: perderne il controllo è il danno più immediato.
Il codice sorgente. Su un repository (GitHub, GitLab o simili) di proprietà dell'azienda, o a cui l'azienda ha comunque accesso completo. E consegnato con continuità, a ogni rilascio, non in un unico pacchetto a fine progetto.
Hosting e servizi cloud. Server, database, backup: account intestati all'azienda e pagati dall'azienda, con il fornitore invitato come collaboratore. Se il fornitore sparisce, i servizi continuano a funzionare e qualcun altro può subentrare.
Gli account degli store. Se hai un'app, deve essere pubblicata su account Apple Developer e Google Play Console intestati alla tua azienda. Trasferire un'app da un account all'altro è possibile, ma è una procedura che conviene non dover affrontare.
Le credenziali dei servizi collegati. Pagamenti, email transazionali, notifiche, mappe, chiavi API: ogni servizio che il software usa dovrebbe essere attivato con un account dell'azienda. Soprattutto quelli su cui passano soldi.
Cosa è giusto che resti al fornitore
Vale la pena essere equilibrati, perché non tutto deve per forza passare al cliente.
Un fornitore esperto usa componenti, librerie e strumenti che ha sviluppato nel tempo e riusa su più progetti. È normale — ed è anche uno dei motivi per cui lavora più velocemente — che quelle parti restino sue, con una licenza d'uso per il tuo progetto. Lo stesso vale per i framework open source, che hanno le proprie licenze.
Quello che conta è che la parte specifica del tuo progetto sia tua, e che le parti riusate non ti impediscano di continuare a usare, modificare o far manutenere il software da qualcun altro.
Le domande da fare prima di firmare
Cinque domande, da fare in modo diretto. Un fornitore serio risponde senza esitazioni.
A chi sarà intestato il dominio? La risposta giusta è: a te.
Dove sarà il codice, e io potrò accedervi? In un repository a cui hai accesso, sempre.
Il contratto prevede la cessione dei diritti o una licenza? Entrambe possono andare bene, purché sia scritto.
Cosa succede se smettiamo di lavorare insieme? Deve esistere una risposta concreta: cosa ti viene consegnato e in che tempi.
Un altro sviluppatore potrebbe subentrare? Serve una documentazione minima: come si installa il progetto, come si pubblica, dove sono i servizi.
Perché un fornitore serio ti dice di sì
Si potrebbe pensare che tenere il cliente legato sia nell'interesse del fornitore. Nel breve periodo, forse. Ma un cliente che resta perché non può andarsene non è un cliente soddisfatto: è un ostaggio, e prima o poi se ne accorge.
Il rapporto sano è quello in cui il cliente potrebbe andarsene in qualsiasi momento, e sceglie di restare perché il lavoro è fatto bene. È un'asticella più alta, ed è quella giusta.
Hai già un software e non sai bene cosa è intestato a chi? Scrivimi: in dieci minuti facciamo insieme il punto su dominio, codice, hosting e account. Queste indicazioni non sostituiscono un parere legale, ma ti dicono dove guardare.
