Negoziare un contratto di sviluppo software

Linux&C n.45

Negoziare un contratto di sviluppo software
di Andrea Monti

Le controversie che si verificano più di frequente nel settore dello sviluppo software riguardano l’incertezza nell’attribuzione dei diritti di proprietà intellettuale, il mancato rispetto dei termini di consegna del programma e la mancanza di accordo sulle funzionalità da implementare. La conseguenza di tutto questo è, nella migliore delle ipotesi, una riduzione del compenso pattuito o la perdita del cliente e, nella peggiore, una causa per inadempimento contrattuale e risarcimento danni. In questo articolo troverete una serie di suggerimenti per minimizzare i rischi di eventualità del genere.

La prima cosa da fare, in assoluto, quando ci si trova nella fase di “negoziazione” con il cliente è stabilire in modo inequivocabile quale sia il “regime giuridico” del rapporto. Cioè se il cliente vuole acquisire il licenza il software che vi commissiona, o se ne vuole diventare il proprietario. La differenza non è banale perché nel primo caso il programmatore è libero di licenziare il software a chiunque, senza che il committente possa opporsi, mentre nel secondo il programmatore cede tutti i diritti di sfruttamento economico e conserva i soli “diritti morali” cioè – essenzialmente – il diritto di essere riconosciuto come “autore materiale” del software. Se si opta per la cessione integrale dei diritti di sfruttamento economico è essenziale definire in modo molto preciso cosa si cede. Questo vale in modo particolare per delle parti – ad esempio, la gestione degli utenti – che essendo sostanzialmente indipendenti dalla particolarità operativa del programma potrebbero essere utilizzate di nuovo per un nuovo cliente. In altri termini (e rimanendo sulla gestione degli utenti): il sistema di creazione e cancellazione degli account, la creazione di gruppi e l’assegnazione dei privilegi e via discorrendo possono funzionare allo stesso modo sia se sto sviluppando un gestionale per commercialisti, sia se sto lavorando a un programma di amministrazione di condomini: è chiaro che, per poter riutilizzare il framework sviluppato per un cliente, non devo averglielo ceduto in via esclusiva. Una soluzione di compromesso è, quindi, quella di ragionare in parallelo: cessione integrale delle parti di specifica competenza del cliente, cessione non esclusiva (e quindi conservazione del diritto di riutilizzo) per le componenti “riciclabili”.

Un altro elemento da tenere presente è la regolamentazione del know how cioè delle competenze che vengono acquisite dal programmatore nell’interazione con il cliente o che, viceversa, il cliente “assorbe” dal programmatore. Il cliente potrebbe infatti voler impedire al programmatore di riutilizzare le competenze acquisite in un certo settore specifico. La ragione di una scelta di questo tipo sta nel fatto che un fattore chiave del successo imprenditoriale sta nell’avere trovato soluzioni tecniche, organizzative e di processo che consentono di ottenere un maggiore vantaggio competitivo sulla concorrenza. Per sviluppare un’applicazione che gestisca questo “patrimonio di conoscenza” (know how appunto), il programmatore deve necessariamente conoscerlo nel dettaglio e dunque, una volta terminato il lavoro, nulla – se non il contratto con il cliente – potrebbe impedirgli di riutilizzare le conoscenze acquisite per fornire prodotti o servizi ai concorrenti del cliente “iniziale”. Allo stesso modo il programmatore potrebbe utilizzare conoscenze proprie per migliorare l’efficienza dei processi gestionali del cliente, e sarebbe ingiusto se dopo averlo fatto, egli si trovasse costretto a rinunciare ai propri “assi nella manica”.

A prescindere dalla scelta compiuta, si dovranno in ogni caso concordare i contenuti della licenza, tenendo presente alcuni aspetti problematici della GPL o di altra licenza libera. Scegliere un licensing open source, può andar bene allo sviluppatore, ma non necessariamente al cliente che, dopo aver investito tempo e soldi nell’applicazione, potrebbe non “gradire” l’essere costretto a consentirne una circolazione sostanzialmente gratuita (certo, si può sempre dire “prendere o lasciare”, ma bisogna poterselo permettere). Dunque bisogna spiegare chiaramente al cliente – e possibilmente per iscritto se intende privilegiare il risparmio sui costi (derivante dal riutilizzo di strumenti già esistenti) o il controllo totale sull’applicazione (che implica la totale riscrittura del codice). Nel compiere la scelta, quindi, sarà necessario considerare gli strumenti di sviluppo, le librerie e i “pezzi di codice” che saranno impiegati nello sviluppo e che potrebbero non lasciare alternative sul tipo di licenza da utilizzare. Se, poi, il livello di coinvolgimento del cliente nella fase di analisi e nelle scelte applicative fosse particolarmente elevato, egli potrebbe addirittura acquistare il ruolo di “coautore” con tutte le conseguenze del caso. Dato che non è possibile stabilire preventivamente il “quando” questo possa accadere, è importante definire fin da subito ruoli e competenze.

Allo stesso modo, è necessario stabilire se lo sviluppo dell’applicazione comprenda anche la realizzazione del materiale di supporto tecnico. Le opzioni sono varie, dal solo commento incluso nel codice sorgente, alla consegna del “progetto”, alla realizzazione di un manuale utente fino all’inclusione nel programma dello help in linea.

Sempre in fase di trattativa è molto importante definire le funzionalità dell’applicazione. Si tratta di una fase critica perché, a stretto rigore, le funzionalità
implicano lo sviluppo del programma, il quale, a sua volta, non può essere sviluppato se non se ne conoscono le funzionalità da implementare. Questo circolo vizioso induce spesso alla commissione di un errore – “intanto cominciamo a lavorare, e poi vediamo” – che si ripercuote negativamente sulla qualità del prodotto e sul rapporto fra cliente e programmatore. “Mettendo mano” al progetto, infatti, emerge sistematicamente e quando oramai è troppo tardi per rinegoziare gli accordi economici, che “ci sarebbe stato bisogno di questa funzionalità” oppure che “era scontato che il programma dovesse fare questa operazione” mentre invece non la prevede. Per evitare di rimanere impantanati in questo modo è opportuno ragionare innanzi tutto per obiettivi, facendosi dire dal cliente, con il maggior grado di dettaglio possibile, quali necessità – necessità, non funzioni – dovrebbero essere soddisfatte dal programma.

Definite le necessità, si passa all’individuazione delle funzionalità essenziali senza le quali il programma sarebbe non idoneo allo scopo, e poi alla definizione delle modalità di interazione fra applicazione e utente note come interaction design. L’interaction design è un concetto sviluppato da Alan Cooper e descritto nel libro The Inmates are running the asylum (tradotto in italiano da Apogeo con il titolo Il disagio tecnologico) che va oltre l’arcinota questione dell’usabilità di un software e studia il “modo” più efficiente in cui un programma deve – o dovrebbe – relazionarsi con l’utente. Descritto in questi termini l’interaction design sembrerebbe una banalità, ma se ci si pensa un attimo si scopre che non è così. Un software potrebbe avere tutte le funzionalità per soddisfare quanto richiesto dal cliente, ma essere talmente farraginoso da essere inutilizzabile, o funzionare secondo delle logiche operative perfettamente comprensibili – poniamo – per un tecnico, ma che sono ostrogoto arcaico per un amministrativo. E’ chiaro che, in questo caso, il cliente potrebbe contestare la qualità del lavoro imponendo di renderlo più adatto ai “comuni mortali” con la conseguenza che il programmatore si troverebbe di fronte all’alternativa secca fra l’imbarcarsi in un contenzioso legale o “rimettere mano” al programma vanificando il guadagno economico.

Garanzia, assistenza e manutenzione costituiscono l’ultimo insieme di “oggetti” da gestire contrattualmente perché clausole come quelle “as is” – “questo software viene consegnato senza nessuna garanzia implicita o esplicita di funzionamento o di soddisfacimento dell’utente” – sono prive di valore giuridico o quantomeno sicuramente discutibili in giudizio. In termini generali non è pertanto possibile escludere totalmente la responsabilità per danno da software difettoso e quindi, piuttosto che “nascondersi” dietro clausole inutili, conviene prendere il toro per le corna e negoziare limiti ragionevoli. Ad esempio, si può decidere che la garanzia viene prestata solo ed esclusivamente su un certo tipo di configurazione hardware e software, oppure che il computer sul quale sarà installato l’applicativo non potrà essere utilizzato con altri programmi. Insomma, tocca lavorare di fantasia per trovare un equo bilanciamento fra le reciproche posizioni. Un discorso analogo vale per assistenza e manutenzione che – a differenza della garanzia – non devono essere obbligatoriamente prestate per legge e quindi sono gestibili con maggiore libertà.

Ovviamente un tema complesso come la negoziazione di un contratto di sviluppo non si può esaurire nell’ambito di un solo articolo, ma già seguire queste indicazioni consentirebbe di ridurre sensibilmente il rischio di perdere soldi, clienti o addirittura entrambi.

Possibly Related Posts: