Contrattualistica IT e proprietà intellettuale
Contratti software e SaaS
scritti su quello che il sistema fa
Un contratto di sviluppo che non dice di chi è il codice, un abbonamento SaaS con un livello di servizio che l’infrastruttura non può garantire, un accordo sui dati che elenca fornitori dismessi da un anno. Sono i tre difetti che troviamo più spesso, e nascono tutti dallo stesso punto: il testo è stato scritto senza guardare il sistema.
Le tre domande a cui quasi nessun contratto risponde
La prima è di chi è il codice. In un contratto di sviluppo su commessa la risposta non è ovvia: si può cedere la titolarità, concedere una licenza d’uso, tenere il committente proprietario del prodotto e il fornitore titolare dei propri componenti riutilizzabili. Tutte soluzioni legittime, che però vanno scritte. Quando non c’è nulla di scritto la questione emerge nel momento peggiore, cioè quando il rapporto con il fornitore finisce.
La seconda è cosa succede se il servizio si ferma. Un SLA copiato da un modello promette percentuali di disponibilità che nessuno ha verificato sull’architettura reale, e prevede penali calcolate su un canone che non copre il danno. La clausola serve, ma va tarata su come il sistema è fatto davvero: dove sono i punti singoli di rottura, quanto dura un ripristino, cosa è escluso perché dipende da terzi.
La terza è chi tratta i dati dei clienti finali. Se vendete software in cloud, quasi certamente siete responsabili del trattamento per conto dei vostri clienti, e i vostri fornitori di infrastruttura sono subresponsabili. Questo va formalizzato in un accordo, con l’elenco aggiornato di chi c’è dentro: un elenco che invecchia ogni volta che cambiate un servizio. Tenerlo allineato è metà del lavoro, e si fa in due: il team legale interno scrive il testo, gli sviluppatori confermano che descriva il sistema che avete davvero in produzione.
Situazioni in cui questo lavoro serve davvero
State per firmare con un cliente grande
Ufficio acquisti e legale interno che chiedono garanzie precise
Vendete in abbonamento
Condizioni d’uso, rinnovi, recesso e limitazioni di responsabilità
Commissionate uno sviluppo
Serve stabilire proprietà, sorgenti e cosa resta a voi alla fine
Usate componenti open source
Licenze compatibili e obblighi che si trasmettono al vostro prodotto
Il vostro contratto ha qualche anno
Descrive un prodotto e una normativa che nel frattempo sono cambiati
Integrate AI di terzi
Cosa promettete sull’output e cosa dice il contratto del fornitore
Concretamente
Cosa consegniamo
Contratti di sviluppo software
Oggetto, milestone, collaudo, gestione delle varianti e, soprattutto, titolarità del risultato e destino del codice sorgente alla fine del rapporto.
Licenze e condizioni d’uso SaaS
Il testo che regola l’abbonamento: perimetro d’uso, limiti, durata, rinnovo, recesso, sospensione del servizio e cosa succede ai dati quando il cliente se ne va.
Livelli di servizio (SLA)
Disponibilità, tempi di risposta e penali costruiti sull’architettura reale, con le esclusioni per ciò che dipende da fornitori terzi scritte in modo verificabile.
Accordi sul trattamento dei dati
Il DPA fra voi e i vostri clienti, con l’elenco dei subresponsabili mantenuto aggiornato e le istruzioni sul trattamento allineate a quello che il software fa.
Proprietà intellettuale
Titolarità del codice, uso di componenti riutilizzabili, marchi e nomi a dominio, con verifica delle licenze open source che avete integrato nel prodotto.
Accordi di riservatezza
NDA proporzionati al progetto, che proteggono davvero le informazioni sensibili senza bloccare il lavoro quotidiano dei team che devono collaborare.
Revisione di contratti ricevuti
Analisi dei testi che vi propongono clienti e fornitori, con l’elenco dei punti da rinegoziare ordinato per rischio concreto e non per gusto redazionale.
Documentazione per gli audit fornitori
Il pacchetto di risposte e allegati da tenere pronto per i questionari dei clienti enterprise, così da non riscriverlo da capo a ogni trattativa.
Dall’analisi alla prima bozza in 2-4 settimane
Analisi del rapporto
Capiamo cosa vendete o comprate davvero: licenza, servizio, sviluppo su commessa, o le tre cose insieme sotto un solo nome. È qui che si decide chi possiede il codice, e quasi nessun contratto standard lo dice in modo chiaro.
Impianto contrattuale
Definiamo la struttura: contratto quadro, condizioni d’uso, SLA, accordo sul trattamento dei dati, allegati tecnici. Meglio pochi documenti coerenti che un contratto lungo che si contraddice da solo tra articolo e allegato.
Redazione
Il team legale scrive i testi, gli sviluppatori verificano che le promesse tecniche siano sostenibili: un SLA che il vostro stack non può rispettare è un rischio che vi siete presi con la firma, non una clausola.
Negoziazione e revisione
Vi affianchiamo nelle trattative con clienti enterprise e fornitori, e rivediamo i contratti quando il prodotto cambia. Un contratto SaaS scritto per la versione di due anni fa descrive un servizio che non vendete più.
FAQ
Contratti software: domande frequenti
Le risposte che diamo più spesso alle aziende che ci scrivono su questo tema.
Solo se il contratto lo dice. In mancanza di una clausola esplicita la situazione è ambigua e si presta a interpretazioni divergenti proprio quando il rapporto si interrompe. Le configurazioni possibili sono diverse: cessione piena, licenza d’uso, oppure proprietà del committente sul prodotto con il fornitore che resta titolare dei propri componenti generici. Nessuna è sbagliata in sé, va scelta consapevolmente e messa per iscritto, insieme alla consegna dei sorgenti.
Quasi sempre sì. Se i vostri clienti caricano dati di persone nella vostra piattaforma, voi trattate quei dati per loro conto e serve un accordo che descriva cosa potete farci, per quanto tempo, con quali misure di sicurezza e attraverso quali subresponsabili. È anche il primo documento che l’ufficio legale di un cliente strutturato chiede, spesso prima ancora del preventivo.
Nella grande maggioranza dei casi sì, ma dipende dalla licenza di ciascun componente. Alcune impongono soltanto di mantenere le attribuzioni, altre estendono i propri obblighi al software che le incorpora, e la differenza conta molto se distribuite il prodotto ai clienti. La verifica si fa sull’elenco reale delle dipendenze: è un controllo tecnico prima che giuridico, ed è uno dei punti dove serve leggere il progetto e non solo il contratto.
Quello che l’architettura può reggere, con un margine. Promettere una disponibilità molto alta su un sistema che ha un singolo punto di rottura significa aver firmato una penale a scadenza. Nella pratica si guarda prima come è fatto il servizio, poi si scrive la clausola: è il tipo di verifica che uno studio legale da solo non può fare, perché richiede di aprire l’infrastruttura.
Di solito no. Si parte da una revisione mirata: cosa è cambiato nel prodotto, quali riferimenti normativi vanno aggiornati, quali clausole descrivono un servizio che non vendete più. Spesso il risultato è un impianto rivisto in alcune parti e un allegato tecnico nuovo, che è un lavoro molto più breve di una riscrittura completa.
Preventivo
Parliamo dei vostri contratti
Descriveteci la situazione, anche in due righe. La prima call è gratuita e senza impegno: serve a capire da dove conviene partire. Rispondiamo entro 24 ore.
Richiesta inviata
Grazie! Ti ricontattiamo entro 24 ore per una prima call gratuita e senza impegno.
Torna alla homeInvio non riuscito
Qualcosa è andato storto. Riprova tra poco oppure scrivici direttamente a info@morfex.it.
RiprovaCollegato a questa pagina
- Adeguamento GDPR Il DPA nasce dalla mappatura dei trattamenti
- NIS2 e D.Lgs. 138/2024 Requisiti di sicurezza che arrivano dai clienti in perimetro
- Sviluppo conforme Perché lo SLA si scrive guardando l’architettura
- Sviluppo software e piattaforme Piattaforme SaaS multi-tenant costruite su misura
- Legal & Compliance L’hub con tutte le aree e il metodo di lavoro