Se ti occupi di sviluppare software, piattaforme e gestionali, ti sarai sicuramente posto già molti quesiti che riguardano gli aspetti legali. In questo articolo voglio condividerti alcune soluzioni, tratte dalla mia esperienza di consulente legale per aziende IT.

Licenza o vendita del software?

Prima di addentrarmi su casi e questioni, facciamo una distinzione:

• si parla di cessione quando viene trasferita la proprietà del software, con codice sorgente, interfaccia, funzionalità e tutto quanto costituisce il know how dell’azienda IT.
• si parla di licenza quando invece viene messo a disposizione un software senza il trasferimento della titolarità, ma dietro pagamento di un canone annuale o mensile (ad esempio).

Di fatto, traducendo la situazione in qualcosa di tangibile, nel primo caso è come se stessimo acquistando una vettura, nel secondo caso è come se la prendessimo in affitto. Purtroppo però, abbiamo a che fare con beni immateriali (software, gestionali, piattaforme, ecc..), che discendono da una pluralità di attività (progettazione, sviluppo, declinazione, ecc..), che richiedono necessariamente un’adeguata protezione, altrimenti, le problematiche sono notevoli e talvolta di difficile soluzione.

Dotarsi di un contratto ben scritto, di un preventivo completo e prima ancora gestire in modo oculato le trattative, sin dal primo contatto, è fondamentale. Sappi che gestiamo anche vari percorsi formativi volti a trasmettere le conoscenze di base per la gestione, sotto il profilo legale, delle trattative con i clienti.

Le principali problematiche legali nello sviluppo software: esempi pratici

Nel corso della mia esperienza, sono stata incaricata a redigere varie tipologie di accordi aventi ad oggetto il software. Alcune volte però il cliente è arrivato a contattarmi “troppo tardi” e quindi abbiamo dovuto intervenire a tutela successiva cercando di dare una soluzione alle problematiche insorte.

1) Il problema della proprietà del codice sorgente

Il servizio di sviluppo e progettazione software dovrebbe prendere la consegna di un file eseguibile o direttamente embeddato nel luogo di destinazione, senza quindi la messa a disposizione delle stringhe che hanno consentito di raggiungere il risultato.

In assenza di contratto, con un preventivo poco chiaro e con una fattura altrettanto interpretabile, talvolta non è scontato. In alcuni casi si è arrivati alla situazione in cui il cliente pretendeva di vietare all’azienda IT di utilizzare il proprio know how (codice sorgente dunque) per altre situazioni, perchè appunto, era stato acquisito.

Come evitare questo problema? È fondamentale definire bene sin dalla fase delle trattative, cosa viene consegnato al cliente, in quali termini, limiti, modalità.

2) Il problema della partnership con il cliente della software house

Talvolta si crea una sorta di partnership tra l’azienda IT che sviluppa un nuovo software, innovativo e il cliente finale che intende concedere in uso ai propri clienti il software. In questi casi, è fondamentale quantificare il lavoro svolto nella fase di sviluppo, definire le % rispetto agli introiti, ma sopratutto anche l’impegno del cliente nella promozione del prodotto.

In questo caso, in assenza di un’adeguata regolamentazione, si rischia di perdere alcune voci. Può essere opportuno quindi tenere a mente, con riguardo ai prezzi:

• il corrispettivo per la fase di sviluppo del software per conto del cliente;
• i canoni per le attività di aggiornamento del software sulla base delle richieste del cliente:
• la percentuale di introiti derivanti dalla messa a disposizione del software agli utenti;
• i compensi per le attività di manutenzione, magari diretta, presso gli utenti.

Come evitare problematiche? È fondamentale partire da un audit approfondito e completo perchè non è detto che tutto debba essere regolamentato all’interno di un unico contratto.

3) Il problema del divieto di concorrenza: i competitor del cliente

Il cliente può imporre alla software house il divieto di commercializzare software simili, dal punto di vista delle funzionalità, nei confronti di soggetti in concorrenza.

Il problema può sorgere qui laddove l’accordo sia generico. E in questi casi, sorgono contenziosi.

La soluzione è quindi quella di stabilire un accordo iniziando da questi quesiti:

• Qual è l’attività vietata? La commercializzazione del medesimo software dal punto di vista dell’interfaccia o di un software, anche visivamente molto diverso, ma con le stesse funzionalità?
• Qual è la durata? Di norma, le clausole che limitano la facoltà di commercializzare con terzi, sono fissate entro limiti temporali e in questo caso si consideri che il software comunque è soggetto sempre a nuovi aggiornamenti che limitano anche la vita utile.
• Qual è il compenso? La limitazione alla facoltà di riutilizzare il know how acquisito per lo sviluppo di quell’applicativo, come viene ricompensata?

4) Il problema della declinazione funzionale

Altro punto fondamentale è comprendere qual è effettivamente l’attività che la software house si impegna a svolgere verso il cliente. Io parlo di declinazione funzionale in tutti i casi in cui lo standard di base sia esistente e a questo vengano (i) aggiunte le funzionalità richieste dal cliente sulla base di un listino messo a disposizione (ii) progettate altre funzionalità non previste nello standard.

Il problema quindi qui può porsi qualora le attività svolte non siano state adeguatamente descritte, anche con riguardo alla proprietà intellettuale del prodotto originario e dei nuovi elementi.

5) Il problema dei malfunzionamenti del software

Nei contratti, di appalto o di vendita, è prevista una responsabilità in caso di vizi e difetti, che deve essere fatta valere entro determinati limiti temporali e che ci consente di identificare cosa si intende per “vizi” e per “difetti”.

Intuisci che con riguardo al software le questioni sono più delicate:

• Il software può essere integrato all’interno del gestionale del cliente e i problemi possono sorgere perchè i due prodotti “non riescono a parlarsi”;
• Il software “non gira” sul luogo di destinazione per ragioni che dipendono dal cliente, il quale ha omesso di fornire informazioni rilevanti;
• Ci sono dei malfunzionamenti che non dipendono da chi ha sviluppato l’APP;

Come risolvere le problematiche? Ci sono varie modalità, in questo caso. Faccio un grande uso degli allegati ai contratti per definire bene il prodotto, le attività, i servizi. In questi casi potrebbe essere utile:

• Allegato 1 : Elenco delle funzionalità del software sulla base delle richieste del cliente;
• Allegato 2: Attività che verranno svolte autonomamente dal cliente (o da terzi) con riguardo al complesso della piattaforma con caratteristiche della stessa;
• Allegato 3: Elenco delle attività di manutenzione con distinguo;

Come scrivere un contratto di sviluppo software: da dove partire

In questo caso (in altri casi fornisco una checklist), ti suggerisco di iniziare dalle problematiche che hai ravvisato sino ad ora nella tua attività di sviluppatore. Mettile nero su bianco e magari, se riesci, individua la ragione da cui è disceso la questione e come, in quel caso, è stata data la soluzione.

Come si sarebbe potuto prevenire il problema?

Quale avrebbe potuto essere la soluzione migliore?

Il problema ha provocato danni economici o all’immagine dell’azienda?

In seconda battuta, prendi nota delle fasi di sviluppo del software, con riguardo alle richieste e al ruolo del cliente.

Il cliente fornisce un elenco di funzionalità di cui ha necessità?

L’azienda IT invia un report delle richieste che deve essere confermato?

Legal for Creativity si occupa di fornire consulenza legale per la redazione di contratti per lo sviluppo di software, gestionali, piattaforme, in base alle esigenze dell’azienda e alle specificità del prodotto e degli accordi con il cliente. Si occupa anche di fornire un’adeguata formazione con riguardo alla gestione di tutti gli aspetti problematici, alcuni dei quali qui esposti, per prevenire le questioni o comunque raggiungere una soluzione.

Foto di Markus Spiske su Unsplash