La progettazione del software, la declinazione delle funzionalità di un asset immateriale, la licenza d’uso di APP in abbonamento, l’aggiornamento di un applicativo pre-installato, la correzione dei bug di un sistema, la manutenzione ordinaria continuativa, la gestione da remoto del database (ecc..) sono tutte attività che devono essere regolate all’interno di uno o più contratti che la software house sottopone al proprio cliente prima di iniziare i lavori.

Come scrivere un contratto per APP

Premessa: all’interno di questo sito internet, in questa sezione, puoi trovare risorse informative utili per inquadrare bene le tue esigenze legali e comprendere quali sono le problematiche di maggiore rilevanza, da prevenire, con riguardo alla tua specifica attività. L’obiettivo quindi non è quello di farti diventare un avvocato ma di comunicarti cosa può essere importante implementare all’interno della tua realtà aziendale.

E quindi, non ti fornirò un format di contratto generico, né alla fine del post potrai metterti a scrivere in via autonoma l’accordo, ma avrai degli strumenti da cui partire focalizzare le tue esigenze, da condividerci.

Le definizioni principali da inserire in un contratto di progettazione APP

La prima questione da affrontare è quella di individuare le definizioni. Ti sembrerà forse una banalità, ma a mio avviso, per evitare fraintendimenti tra te e il tuo cliente, che possono diventare vertenze e sfociare addirittura in contenziosi, è fondamentale che i primi articoli riportino cosa si intende per ciascuna delle attività, dei servizi, dei prodotti e di tutto quanto intendiamo regolamentare nel contratto.

Ad esempio:

• Cosa si intende per “software”? Si tratta del file eseguibile che verrà messo a disposizione del cliente oppure si tratta del codice sorgente che viene sviluppato e sorregge l’eseguibile?
• Cosa si intende per “sviluppo”? Include anche l’attività di progettazione oppure si tratta di declinazione di un prodotto esistente di proprietà dell’azienda IT?
• Cosa si intende per “interfaccia”? Può essere utile definirla anche con riguardo poi all’eventuale richiesta da parte del cliente di non sviluppare qualcosa di simile per i competitor.

Ovviamente, questi sono solo tre esempi. Talvolta i contratti che il team di Legal for Creativity redige, possono contenere anche un foglio intero di definizioni. Questo unicamente perchè vogliamo chiarezza e assicurarci un’interpretazione più oggettiva possibile.

L’oggetto del contratto: le fasi di sviluppo del software

La seconda questione da affrontare è l’oggetto del contratto, ossia la prestazione principale che l’azienda IT si impegna a svolgere a favore del proprio cliente.

L’oggetto può essere descritto in modo sintetico, ma deve contenere, senza possibilità di diversa interpretazione esattamente cosa si impegna a svolgere l’azienda IT.

E quindi: progettazione, sviluppo, declinazione funzionale, messa a disposizione, aggiornamento, manutenzione continuativa, integrazione, progettazione dell’interfaccia utente, ideazione di meccanismi di facilitazione, ecc.

Per aiutarci a definire bene l’oggetto del contratto, basta che pensiamo alle fasi del lavoro. È fondamentale una pianificazione, anche dividendola, se previsto, per stati di avanzamento e determinando poi, per ciascuna fase, qual è il ruolo del cliente.

La proprietà intellettuale del software e il know how della software house

È importante che il cliente comprenda cosa si intende per: codice sorgente, versione beta, eseguibile, interfaccia e tutto quanto necessario per poi comprendere a chi spettano i diritti su quanto realizzato.

Di norma, ma questo cambia in ragione all’attività della software house, distinguo tra:

• “background IP”: tutto quanto c’era prima che il cliente conferisse l’incarico; il know how, i dati, le informazioni, le stringhe di codice e tutto quanto costituisce il “format” di base su cui poi l’azienda procede con le attività di progettazione, scrittura, definizione;

La background IP, oltre ad essere di esclusiva proprietà dell’azienda IT, non deve essere in alcun modo ceduta, ma nemmeno messa a disposizione in chiaro. Si tratta dell’avviamento della software house e quindi dell’asset immateriale più prezioso per il lavoro.

• “foreground IP”: tutto quanto sviluppato, declinato, progettato e tradotto in codice, nel corso del contratto; il cliente ha quindi richiesto quell’APP e la software house, partendo dal proprio asset e quindi dalla background IP, procedere nello sviluppo di quanto richiesto.

La foreground IP, sotto il profilo dei diritti morali, è di titolarità della software house. Con riguardo invece ai diritti di utilizzazione economica, questo dipende dagli accordi assunti con il cliente finale. A mio avviso è sempre bene distinguere i due profili di proprietà intellettuale ma mantenere anche questo in capo esclusivo dell’azienda IT. Semplicemente, sarà messo a disposizione, in licenza o in cessione, l’eseguibile originato dalle implementazioni e dunque anche attraverso la foreground IP.

Questo chiaramente non consente alla software house, domani, di vendere esattamente lo stesso software a terzi, sviluppato per conto del cliente, acquisita la foreground IP.

In questo senso quindi, sono da prevedersi dei limiti e un bilanciamento delle posizioni delle parti.

Queste valutazioni vanno quindi compiute anche avuto riguardo:

1. All’oggetto del contratto: declinazione di un funzionalità esistenti oppure odine di sviluppo di qualcosa di nuovo?
2. Alla presenza di un’esclusiva o non concorrenza: richiesta di non commercializzazione di un prodotto simile con riguardo alle funzionalità o all’aspetto?
3. Alla modalità di gestione dell’interfaccia grafica e della titolarità del design (potrebbe essere l’unico aspetto davvero rilevante per il cliente);

Il format di contratto e la gestione degli allegati

Come anticipato, non posso fornirti un modello di contratto che vale per tutte le software house che sviluppano applicativi per aziende. In questo articolo ho voluto condividerti solo alcuni dei principali punti che devono essere valutati per poi andarli a formalizzare in un documento contrattuale.

Quello che però posso dirti è che, non necessariamente poi devi dotarti di un contratto ad hoc per ogni cliente. Se sei verticale su un complesso di attività e si riesce a regolamentarle allo stesso modo, sarà sufficiente un accordo unico che poi potrai adattare anche autonomamente attraverso gli allegati.

Foto di ThisisEngineering RAEng su Unsplash