Il cliente e lo sviluppatore

di a cura di Carlo Piana - 9 dicembre 2013

(Appunti per il soggetto di un film dell'orrore, basato su una storia vera. Ogni riferimento a fatti e circostanze reali è puramente voluto).

Un programma, un sito web, un'app per smartphone. Commissionata a un serissimo operatore con una bellissima brochure, che vi fa un bellissimo progetto, il costo non è nemmeno molto, questo è quello che fa per noi. Ok, firmiamo la commissione d'ordine, non vediamo l'ora di avere tra le mani il lavoro finito. Passano due anni, l'applicazione va aggiornata alla nuova legge, il sito web non è più attuale, ora serve la versione per Android. Cosa fare? Torniamo dalla nostra serissima società per un preventivo. Che sarà mai? Due righe di codice, un paio di giorni.

La serissima società è stata ora acquistata da una ancora più seria multinazionale. I prezzi sono un po' più alti. Molto più alti. Il preventivo è oltraggioso. Bene, andiamo da qualcun altro. Cambio di scena, sala riunioni (si fa per dire) in un open space alla periferia. Questi ragazzi sono quello che ci vuole, svegli, aperti, un sacco di idee nuove, molto più a buon mercato. "Ok, cominciamo" dice quello più anziano (si fa per dire, avrà ventitré anni) "ci date il codice sorgente, vediamo cosa possiamo riutilizzare". Ehm il cosa? No, non l’abbiamo, poco male, torniamo da quegli altri e ce lo facciamo dare. La risposta però non ci piacerà, siamo vittime di un gioco non bello.

Il gioco si chiama "lock-in".

Il lock in è un locale dove l'entrata è a buon mercato, l'uscita no. Se vogliamo avere il codice, dobbiamo pagare, salato. Se va bene, altrimenti è no e basta, "il codice è nostra proprietà". Macché, sul contratto non c'era scritto niente, orecchie basse, o si rifà tutto, o si accetta il preventivo alto, il progetto meno entusiasmante, costa sempre meno che fare tutto da capo. Il lock-in non ci fa uscire. Vicolo cieco. Con la prospettiva fra due anni di essere ancora nella stessa situazione. Mah, si vedrà.

"Ora questo ci dirà", penserete "che dovevamo andare dall'avvocato prima, la solita automarchetta". No! Be', un po' sì, ma non necessariamente. Ecco alcuni suggerimenti minimali su cosa fare per evitare di trovarsi nella situazione di lock-in.

Se pagate per il codice, chiedete che il codice sia vostro. Non importa se è un'applicazioncina o la consolle di controllo di una centrale nucleare. Non è necessaria la titolarità, potrete negoziare un costo più limitandovi a ricevere una licenza personale illimitata, estesa allo sviluppo in proprio e da parte di terzi. La società di software garantirà che ogni componente necessario sarà comunque disponibile. Meglio ancora, fate un sorriso largo così se le componenti sottostanti sono software libero (open source), questo garantisce indipendenza dal fornitore e ampia libertà di sviluppo.

Garanzie. Non crederete quante volte anche multinazionali si trovano a reimpiegare software per il quale il fornitore non ha una licenza sufficiente a trasmettere tutti i diritti necessari. Può capitare anche a voi. Controllate sempre che ci sia una garanzia a che tutto il codice sia originale o adeguatamente licenziato in modo da poter in ogni caso esercitare tutti i diritti previsti dal contratto. Controllate anche la limitazione di responsabilità. Una garanzia senza adeguata responsabilità vale poco. Se c'è, deve essere almeno pari al costo totale corrisposto al fornitore, per avere una certa serietà. Nel caso di applicazioni dal costo più rilevante, una due diligence sulle licenze a monte è qualcosa di consigliabile, in aggiunta alla garanzia.

Standard, standard, standard! Fate in modo che il più possibile l'applicazione utilizzi standard ampiamente adottati e liberi da brevetti (open standard). Molto spesso questi sono imposti dalla legge o dall'ambiente, ma la scelta dovrebbe essere sempre in quella direzione.

Manutenzione. È normale che il software non abbia una garanzia per i vizi. Nel caso del software libero, questa è anzi la regola invariabile. Non è sbagliato, ma voi dovrete avere cura di garantirvi un periodo adeguato nel quale, a pagamento (a canone) il fornitore garantisce la correzione degli errori e magari anche la manutenzione evolutiva (specie nel caso in cui la normativa applicabile è certo che cambierà). Se l'applicazione è basata su software libero, abbiate cura che le componenti siano attivamente manutenute dalla comunità, questo diminuirà i costi.

In conclusione, seguendo questi pochi consigli eviterete gli incidenti che con troppa frequenza incontro nella mia professione. Se poi volete essere più tranquilli (qui parte la “marchetta”), rivolgetevi a un esperto. Se lo è veramente, potrebbe costare meno di quanto pensiate. Ma chiedete un preventivo...

 

Carlo Piana

@carlopiana


0 Commenti :

Commento

Captcha

A CURA DI CARLO PIANA

/media/5648275/piana.png
DIRITTO NUOVE TECNOLOGIE
Account twitter Account LinkedIn Feed RSS

Rubrica in collaborazione con Simone Aliprandi e Alberto Pianon di Array Avvocato esperto di diritto delle nuove tecnologie, si occupa di tutela del software, informatica nei servizi pubblici, antitrust, marchi e nomi a dominio e molto altro.

Noto per l'impegno per il software libero e le libertà digitali, è editor della International Free and Open Source Software Law Review. Nel 2008 ha fondato Array, network di legali specializzati in ICT law - http://arraylaw.eu

Impresa
Se le leggi offrono poca ospitalità alla sharing economy: i problemi sollevati da AirBnB
30 novembre 2016

Grane legali per Facebook. Quando i social media diventano veicolo di contenuti illeciti
17 novembre 2016

"Secondary ticketing” o bagarinaggio 2.0?
3 novembre 2016

ARCHIVIO