Saltar al contenido
Qoode
  • Scegliere un fornitore

Il codice è vostro? Cosa chiedere prima di firmare

Cinque domande da fare a qualunque fornitore di software, cosa significa davvero «il codice è vostro» e come si evita di restare ostaggio di chi ha costruito il sistema.

Qoode5 min de lectura
Le cinque domande da fare a un fornitore di software prima di firmare: di chi è il codice sorgente, dove sta il repository, chi controlla dominio e hosting, come si esportano i dati e chi può proseguire il lavoro.

La telefonata arriva sempre con lo stesso tono. Il fornitore che ha costruito il gestionale non risponde più, oppure ha alzato il canone, oppure ha chiuso. E la domanda è: possiamo prendere quello che c'è e portarlo da un'altra parte?

Quasi sempre la risposta dipende da cinque cose decise anni prima, in un contratto che nessuno ha letto con attenzione perché all'epoca il rapporto era buono. Questa guida elenca le cinque domande, spiega cosa significa davvero «il codice è vostro» e cosa fare se avete già firmato senza chiederlo.

Le cinque domande

Le cinque domande da fare a un fornitore di software prima di firmare: di chi è il codice sorgente, dove sta il repository, chi controlla dominio e hosting, come si esportano i dati e chi può proseguire il lavoro.
Un fornitore serio risponde a tutte e cinque senza esitare. L'esitazione è già la risposta.

Vanno fatte a chiunque — noi compresi — e vanno fatte prima, quando avete ancora il potere contrattuale. Dopo si trattano, non si chiedono.

1. Di chi è il codice sorgente?

«Il software è vostro» non significa niente: significa che potete usarlo. La domanda giusta è chi detiene i diritti sul codice sorgente e cosa potete farci — modificarlo, farlo modificare a terzi, riutilizzarlo.

Se la risposta non è scritta nel contratto, in Italia i diritti restano tipicamente a chi lo ha scritto. La cessione va pattuita, non presunta.

2. Dove sta il repository?

Il codice può essere formalmente vostro e materialmente irraggiungibile. Se vive in un account del fornitore a cui non avete accesso, il giorno che serve dovete chiederlo — e chiederlo è una posizione debole.

La configurazione sana è banale: l'organizzazione su cui sta il codice è intestata a voi, il fornitore è un collaboratore. Costa zero e cambia tutto.

3. Chi controlla dominio e hosting?

È la leva usata più spesso quando un rapporto finisce male, e quasi sempre per disattenzione più che per malizia: l'agenzia ha registrato il dominio a proprio nome perché era più comodo, e tre anni dopo quella comodità è diventata un problema.

Il dominio deve essere intestato a voi. L'hosting e i servizi cloud dovrebbero stare su account vostri, con il fornitore che ha accesso — non il contrario.

4. Come si esportano i dati?

Vale per il su misura e vale doppio per i prodotti in abbonamento. La domanda non è «si può esportare», che è quasi sempre sì: è in che formato, quanto è completo, quanto tempo richiede e se serve l'intervento del fornitore per ottenerlo.

Un export che restituisce PDF invece di dati strutturati è un export che non serve a niente. Chiedete di vederne uno prima di firmare, sui dati di prova: dura dieci minuti e dice tutto.

5. Chi può proseguire il lavoro?

Un altro fornitore riesce a capire quel codice senza ripartire da zero? Esiste una documentazione che spiega come si installa, come si aggiorna, quali servizi esterni usa e con quali credenziali?

È la domanda più difficile da verificare prima e la più importante. Un modo pratico c'è: chiedete che la documentazione di installazione esista fin dalla prima consegna e che venga aggiornata a ogni rilascio, come parte del lavoro e non come extra.

Un fornitore serio risponde a tutte e cinque senza esitare, perché sono le condizioni in cui lavora normalmente. L'esitazione non è un dettaglio: è già la risposta.

Cosa non significa «il codice è vostro»

  • Non significa che potete farne a meno del fornitore domani: serve comunque qualcuno che sappia leggerlo.
  • Non significa che il fornitore non possa riutilizzare le proprie librerie interne. È normale e va scritto: sono strumenti suoi, non il vostro sistema.
  • Non significa che i componenti open source usati diventino vostri. Restano con la loro licenza, ed è un bene.
  • Non significa niente se non è nel contratto. Una promessa a voce in fase di vendita vale quanto la memoria di chi l'ha fatta.

Se avete già firmato senza chiederlo

  1. 01Guardate il contratto e cercate le parole «proprietà», «licenza» e «cessione». Se non ci sono, la situazione è ambigua — e l'ambiguità di solito non gioca a vostro favore.
  2. 02Chiedete un accesso in lettura al repository. È una richiesta ragionevole e la risposta vi dice in che rapporto siete.
  3. 03Verificate a chi è intestato il dominio: si controlla in trenta secondi ed è la cosa più facile da sistemare.
  4. 04Fate un export completo dei dati adesso, mentre il rapporto è buono, e conservatelo. Non serve per andarsene: serve per sapere che potreste.
  5. 05Al primo rinnovo, mettete per iscritto quello che manca. Un rinnovo è il momento in cui avete di nuovo potere contrattuale.

Come lo facciamo noi, per chiarezza

Il codice è del cliente ed è scritto nel contratto. Il repository sta su un'organizzazione intestata a lui, con noi come collaboratori. Dominio, hosting e servizi cloud sono su account suoi. La documentazione di installazione esiste dalla prima consegna e si aggiorna a ogni rilascio.

Non è generosità: è la condizione che rende il rapporto sano. Un cliente che resta perché non può andarsene non è un cliente soddisfatto, ed è un rapporto che prima o poi finisce male comunque.

Le stesse condizioni sono scritte nella pagina sullo sviluppo di software su misura, insieme a come strutturiamo le consegne per fasi.

Domande frequenti

Il codice su misura costa di più se ne chiedo la proprietà?

Con alcuni fornitori sì, ed è una scelta commerciale legittima purché dichiarata. Quello che non è legittimo è non parlarne e lasciare che il cliente lo scopra quando serve. Chiedete che la condizione sia esplicita nel preventivo, in un senso o nell'altro.

Vale anche per un sito web?

Vale soprattutto per un sito, perché lì il problema del dominio è più frequente. E vale per i contenuti: le foto e i testi che avete pagato sono vostri, e i file originali dovreste averli voi, non solo le versioni pubblicate.

E se uso un prodotto in abbonamento?

Il codice non sarà mai vostro e va bene così. Le domande che restano sono la quarta e la quinta: come escono i dati e in che formato. Su un prodotto in abbonamento sono le uniche due che vi proteggono.

Serve un avvocato?

Per un progetto piccolo bastano le cinque domande e un contratto che risponda per iscritto. Sopra una certa cifra sì, e costa una frazione di quello che costa scoprire dopo che il sistema su cui gira l'azienda non è vostro.

In sintesi

Cinque domande, tutte da fare prima: di chi è il codice, dove sta, chi controlla dominio e hosting, come escono i dati, chi può proseguire. Nessuna è scortese e nessuna mette in difficoltà un fornitore che lavora bene.

Se avete un sistema esistente e non sapete rispondere a queste domande, la verifica si fa in un pomeriggio e conviene farla adesso, non il giorno che serve. Si parte da una conversazione.

  • Contratti
  • Software su misura
  • Scelta fornitore
Todos los artículos