Sviluppatori di software e Check-up contrattuale.

In Italia abbiamo tantissimi sviluppatori di software. Piccoli, meno piccoli e grandi. Ne abbiamo assistiti tanti e - quasi sempre - piccoli o grandi che fossero alla fine venivano da noi perché avevano lo stesso problema. Ma quasi sempre era già tardi.

Quando una impresa nasce, non ha tante pretese: deve affermarsi sul mercato verso concorrenti che già vi operano, dunque lavora sodo e gestisce il suo business in una ottica di limitazione dei costi e di qualità del servizio: sviluppa prodotti innovativi ed efficaci e li propone al mercato. Sta in via di principio assai più attenta al "cosa" fornisce (ossia alla qualità del prodotto e del servizio) rispetto al "come" fornisce (ossia al modo in cui scrive i contratti con i clienti sia di fornitura del programma che di manutenzione correttiva ed evolutiva). Ma le cose non vanno diversamente sul versante interno: contratti di lavoro e collaborazione che non chiariscono bene chi è titolare di che cosa.

Passano gli anni e chi è bravo inizia a rendersene conto: ha affinato il programma, l'ha migliorato e l'ha sviluppato. Dunque vorrebbe monetizzare questi suoi progressi. Quando però inizia a tastare i clienti, per rinnovare i contratti in scadenza a condizioni differenti, scopre che il più delle volte - a causa del "come" erano stati scritti i contratti precedenti - si trova con clienti che - di fronte alle pretese del fornitore - sostengono di avere in mano loro il pallino: magari hanno in mano il sorgente, magari sostengono di essere i titolari delle modifiche apportate. A volte - addirittura - accampano pretese di titolarità esclusiva (o di contitolarità) sul core del programma.

Ma lo stesso accade nel caso in cui si voglia vendere l'impresa, o cercare un partner finanziario o industriale: arriva l'esercito dei legali della controparte che - dopo attenta analisi - demolisce il valore del vostro software e, per l'asset principale della vostra attività, vi offre due euro bucati o condizioni capestro per la partnership.

A volte, infine, sono i collaboratori o gli ex collaboratori o dei subfornitori di servizi a dare a posteriori dei grattacapi : se ne vanno e iniziano a fare cose simili. E di fronte alle diffide sostengono di essere i titolari dei diritti di autore sui programmi.

Il punto è che nove volte su dieci non è affatto chiaro chi abbia ragione, perché i contratti su cui si basano le pretese dello sviluppatore sono stati scritti nell'ottica di monetizzare in fretta e non di tutelarsi per il futuro. Clausole vaghe o generiche su punti essenziali, format non adatti, allegati incomprensibili, catene di rinnovi contrattuali difficili da decifrare, addirittura difficoltà nel definire le varie versioni del programma via via fornite e sviluppate. Quando si inizia a litigare su queste cose, è davvero impossibile prevedere dove e come si finisce.

Come si evita tutto questo? Si evita verificando i propri contratti PRIMA che debbano essere rinnovati o prima di avviare operazioni straordinarie.

Se dunque siete sviluppatori di software e i vostri programmi cominciano a piacere al mercato. Se avete tanti clienti e tante diverse versioni customizzate dei vostri programmi. Se avete distribuito sorgente a questo e quello. Se avete accordi di manutenzione evolutiva che vi fanno trovare soluzioni che poi volete usare anche con altri clienti. Se volete espandere la vostra attività o anche cederla. Ebbene - se vi trovate in questa situazione - vi consigliamo di fare un bel check up dei vostri format contrattuali (forniture, licenze, application maintenance evolutiva e correttiva, escrow, accordi con i dipendenti, con i collaboratori a contratto e con i subfornitori). Potreste scoprire delle cose interessanti e, va detto in anticipo, spesso non particolarmente piacevoli: ma i check up a questo servono: scoprire i problemi e correggerli prima che diventino disastri.