Risposta in breve. In un accordo di co-sviluppo la proprietà di brevetti, software, design, dati e know-how non dovrebbe essere lasciata a formule generiche come “i risultati appartengono alle parti”. Prima dell’avvio occorre distinguere la background IP, cioè ciò che ogni partner porta nel progetto, dai risultati generati durante la collaborazione; stabilire chi può depositare, usare, concedere in licenza e migliorare ciascun risultato; regolare costi, territori, campi d’uso, pubblicazioni, segretezza e uscita dal progetto. Titolarità e diritto di sfruttamento non sono sinonimi: una parte può restare proprietaria e concedere all’altra una licenza mirata.
Aggiornato al 6 ottobre 2026. Autore: Avv. Carmine Coviello.
Principio operativo: il contratto deve consentire di rispondere, per ogni asset, a cinque domande: chi lo possedeva prima, chi lo ha creato, chi ne diventa titolare, chi può sfruttarlo e che cosa accade alla fine della collaborazione.
Perché la titolarità IP va decisa prima di sviluppare
I progetti con startup, software house, università, laboratori, fornitori e partner industriali combinano contributi diversi: codice preesistente, algoritmi, prototipi, disegni, database, segreti tecnici, marchi e capacità produttive. Il problema emerge spesso tardi, quando bisogna depositare un brevetto, presentarsi a un investitore, concedere una licenza oppure vendere il prodotto.
Una fattura pagata o la semplice qualifica di “committente” non risolvono automaticamente ogni profilo di proprietà intellettuale. Le regole cambiano a seconda del bene, del ruolo dell’autore o inventore, del rapporto di lavoro e della legge applicabile. Per questo una due diligence sulla titolarità e sulla catena dei diritti controlla contratti, cessioni, licenze, contributi dei collaboratori e prove di creazione.
La Convenzione sul brevetto europeo, articolo 60, collega il diritto al brevetto all’inventore o al suo avente causa e rinvia, per le invenzioni dei dipendenti, alla legge nazionale individuata dalla norma. In Italia il Codice della proprietà industriale disciplina, tra l’altro, il diritto al brevetto e le invenzioni dei dipendenti agli articoli 63 e 64. Per software e banche dati creati dal dipendente nell’esecuzione delle mansioni o su istruzioni del datore opera inoltre l’articolo 12-bis della legge sul diritto d’autore, introdotto nella formulazione attuale dal decreto legislativo 169/1999. Queste regole non sostituiscono un contratto di co-sviluppo calibrato sul progetto.
Background IP e risultati: la mappa da allegare al contratto
La background IP comprende brevetti, codice, librerie, modelli, dati, documentazione e know-how che una parte controlla prima del progetto o sviluppa fuori dal suo perimetro. La foreground IP indica invece i risultati prodotti nell’attività comune. La distinzione è utilizzata anche nei progetti europei: la Commissione ricorda che il background può includere dati, informazioni e know-how, non soltanto diritti registrati, e che va identificato per iscritto. Si veda l’approfondimento ufficiale dell’European IP Helpdesk sul background nei progetti finanziati.
L’allegato IP non dovrebbe limitarsi a un elenco di numeri di brevetto. È utile indicare versione e data del software, repository, moduli open source, dataset, documenti tecnici, restrizioni derivanti da licenze precedenti, persone autorizzate e finalità per cui il partner può utilizzare ogni risorsa. Se un asset non è necessario, non va concesso con un’autorizzazione più ampia del necessario.
| Asset | Rischio tipico | Previsione contrattuale |
|---|---|---|
| Brevetti e invenzioni | Inventori non identificati o domanda depositata dal soggetto sbagliato | Procedura di invention disclosure, titolare del deposito, territori, costi e decisioni sulle rivendicazioni |
| Software e database | Codice di terzi o componenti non trasferibili | Repository, autori, licenze, accesso al sorgente, manutenzione, escrow e component inventory |
| Design e documentazione | Confusione tra file di progetto, registrazione e diritti d’autore | Cessione o licenza, diritto al deposito, varianti e materiali promozionali |
| Know-how e dati riservati | Perdita della segretezza o uso oltre lo scopo | Classificazione, accessi need-to-know, sicurezza, restituzione e cancellazione verificabile |
Chi deve possedere i risultati del co-sviluppo?
Non esiste una soluzione corretta per ogni progetto. L’assetto più efficiente dipende dai contributi e dal modello commerciale. Le opzioni principali sono tre.
1. Proprietà del soggetto che genera il risultato
Ogni parte conserva i risultati creati autonomamente e concede all’altra i diritti necessari al progetto. È un modello chiaro quando le attività sono separabili, ma richiede criteri oggettivi per i risultati misti e una licenza sufficiente a evitare che il prodotto finale resti bloccato.
2. Proprietà concentrata in una parte con licenza all’altra
Può essere preferibile quando un partner finanzia e commercializza il prodotto, mentre l’altro fornisce R&D o sviluppo. La cessione deve descrivere i diritti trasferiti; la licenza di ritorno può essere limitata per settore, territorio, clienti o applicazioni. Occorre regolare miglioramenti, sublicenze e uso del know-how residuo.
3. Contitolarità
La contitolarità appare equilibrata, ma può rendere lente le decisioni. Il contratto deve stabilire chi deposita e mantiene i titoli, come si dividono i costi, se ciascun contitolare può concedere licenze, chi agisce contro i contraffattori, come si ripartiscono ricavi e risarcimenti e che cosa accade in caso di disaccordo. Senza una governance concreta, “50 e 50” rischia di diventare un veto reciproco.
La guida WIPO sugli accordi di trasferimento tecnologico e collaborazione evidenzia proprio la necessità di regolare background, risultati, riservatezza e possibili diritti condivisi. Per il versante brevettuale, una verifica di Freedom to Operate prima della commercializzazione resta distinta dalla titolarità: possedere il proprio risultato non garantisce di poterlo sfruttare senza interferire con brevetti altrui.
Le 10 clausole essenziali di un accordo di co-sviluppo
- Perimetro e deliverable: attività, specifiche, milestone, criteri di accettazione e responsabili.
- Background IP: inventario allegato, esclusioni, limitazioni e garanzia del diritto a concederne l’uso.
- Risultati e attribuzione: regole per risultati individuali, congiunti, divisibili e non divisibili.
- Inventori e autori: obbligo di registrare i contributi e di firmare gli atti necessari a deposito, cessione o licenza.
- Deposito e mantenimento: chi decide, chi paga, quali paesi coprire e come gestire abbandono o estensione.
- Licenze e sfruttamento: esclusiva o non esclusiva, territorio, campo d’uso, sublicenze, royalties e rendicontazione.
- Componenti di terzi: approvazione preventiva, registro delle dipendenze e compatibilità delle licenze. Un audit delle licenze software riduce il rischio che codice proprietario, SaaS o open source impongano obblighi inattesi.
- Segretezza e sicurezza: classificazione, accessi, divieto di uso estraneo, misure tecniche, incidenti, restituzione e cancellazione.
- Garanzie e responsabilità: titolarità, poteri di licenza, conoscenza di diritti di terzi, limiti, manleva e gestione delle contestazioni.
- Uscita e controversie: effetti della scadenza o risoluzione, continuità operativa, licenze sopravviventi, legge, foro o arbitrato.
Per accordi destinati a mercati esteri, le regole IP devono essere coordinate con distribuzione, produzione e canali commerciali. È utile confrontare anche le clausole IP nel contratto con il distributore estero: un partner commerciale non dovrebbe ricevere, per inerzia, diritti più ampi di quelli necessari a promuovere e vendere il prodotto.
Know-how e software: la proprietà non basta
Il know-how mantiene valore finché resta riservato e viene protetto con misure coerenti. La WIPO indica, tra le misure ragionevoli, controllo degli accessi, sicurezza informatica, marcatura dei documenti e accordi di riservatezza con dipendenti e partner: si vedano le FAQ ufficiali WIPO sui segreti commerciali. Un NDA isolato non è sufficiente se repository, cartelle e prototipi sono accessibili senza tracciamento.
Nel software vanno identificati almeno codice preesistente, codice nuovo, librerie di terzi, modelli AI, dati di addestramento, API, documentazione, credenziali e infrastruttura. Serve inoltre una prova ordinata delle versioni e dei contributi. Il video dello Studio Legale Coviello su come funziona il copyright chiarisce la distinzione tra idea ed espressione e tra diritti morali e patrimoniali; la relativa pagina con trascrizione del video sul copyright è utile anche per inquadrare la protezione del codice.
Checklist prima della firma e prima del lancio
- Elencare ogni asset preesistente con titolare, versione e restrizioni.
- Verificare i contratti di dipendenti, amministratori, freelance, università e subfornitori.
- Definire chi approva pubblicazioni, demo, pitch, fiere e comunicati prima del deposito.
- Aprire un registro delle invenzioni e dei contributi, con date e documenti di supporto.
- Stabilire proprietà, licenze e diritti sui miglioramenti per ogni categoria di risultato.
- Controllare licenze software, dati e materiali di terzi prima dell’integrazione.
- Separare la verifica di titolarità dalla ricerca di anteriorità e dalla Freedom to Operate.
- Prevedere cosa accade a codice, dati, prototipi e licenze in caso di ritardo, recesso o insolvenza.
- Allineare accordo di co-sviluppo, NDA, ordini, licenze, distribuzione e patti con investitori.
- Costruire una data room aggiornata, pronta per finanziamenti, licensing o operazioni societarie.
Un’analisi legale è particolarmente utile quando partecipano più inventori, il progetto combina brevetti e software, sono coinvolti paesi diversi o un investitore richiede prova della titolarità. L’approfondimento dello Studio su quando coinvolgere un avvocato brevetti nei contratti e nei progetti con più soggetti illustra i principali segnali di rischio.
Domande frequenti
Se pago lo sviluppo, divento automaticamente proprietario del software?
Non sempre. Il pagamento remunera la prestazione, ma titolarità e ampiezza dei diritti dipendono dalla legge applicabile, dal rapporto con chi ha creato il software e dal contratto. È prudente indicare espressamente cessione o licenza, sorgenti, documentazione, componenti di terzi e diritto di modifica.
Background IP e foreground IP devono essere cedute?
No. Il background può restare al proprietario ed essere concesso in licenza per lo scopo del progetto. Anche i risultati possono essere attribuiti a una parte con licenze all’altra. L’obiettivo è garantire uso e commercializzazione senza trasferire più diritti del necessario.
La contitolarità al 50% è la soluzione più equa?
Non necessariamente. Può essere adatta a contributi realmente congiunti, ma richiede regole su depositi, costi, licenze, enforcement, ricavi e decisioni. Se manca la governance, la contitolarità può rallentare investimenti e accordi commerciali.
Un NDA protegge tutto il know-how del progetto?
L’NDA è importante ma deve essere accompagnato da misure operative: accessi limitati, repository separati, marcature, policy, formazione, registri e procedure di restituzione o cancellazione. La protezione del segreto dipende anche dalle misure concretamente adottate.
La titolarità del brevetto dimostra la libertà di vendere il prodotto?
No. Il brevetto protegge una soluzione, mentre la Freedom to Operate valuta il rischio di interferire con diritti anteriori di terzi nei mercati di interesse. Le due analisi hanno oggetto e finalità differenti.
Valutare un accordo di co-sviluppo
Prima di condividere codice, prototipi o informazioni riservate, conviene verificare la catena dei diritti e tradurre il modello commerciale in clausole applicabili. Per un’analisi di background IP, risultati, licenze, segretezza, depositi e scenari di uscita, è possibile richiedere una consulenza sul contratto di co-sviluppo e sulla titolarità IP.
Nota: questo contenuto ha finalità informativa e non sostituisce l’analisi del contratto, della legge applicabile e delle circostanze del singolo progetto.