Come sistemare la proprietà intellettuale prima del primo round: guida completa all’IP assignment per startup e imprese tech
Prima di un round seed o Series A, la proprietà intellettuale — codice, repository, documentazione tecnica, dataset e modelli AI — deve avere una catena di titolarità chiara e documentata a favore della società. Senza IP assignment e clausole corrette nei contratti, il software può restare di proprietà di founder, dipendenti o consulenti, creando problemi concreti in fase di due diligence, investimento e M&A. In questo articolo vediamo come mappare gli asset, gestire l’open source e far firmare subito i documenti giusti.
1. Perché la proprietà intellettuale deve essere sistemata prima del primo round
Sistemare la proprietà intellettuale prima del primo round non è un esercizio formale: è una condizione pratica per chiudere un investimento senza ritardi. Investitori — business angel, fondi seed e Series A — chiedono prove che la società possieda davvero il copyright sul software e i diritti su asset come dataset e modelli AI.
Le checklist operative di fundraising sono chiare: l’IP assignment è un’azione pre-seed, con una tempistica tipica di 1–2 mesi. Nella pratica, la mancanza di una catena di titolarità chiara blocca la due diligence o impone condizioni sfavorevoli come escrow, indemnity o carve-out.
Nel contesto UE, la proprietà intellettuale include marchi, brevetti, diritto d’autore e diritti connessi: un perimetro ampio che va presidiato fin dall’inizio. Per le startup italiane è utile incrociare questi requisiti con la compliance prevista per le startup innovative.
Il punto che vediamo più spesso nel nostro lavoro con startup tech è che l’IP non è un tema legale: è un asset finanziario che deve essere trasferibile, auditabile e difendibile.
2. Chi possiede davvero il codice, il prodotto e i dati se manca un IP assignment?
Senza un IP assignment, il presupposto “il software è della società perché l’ha pagato” è spesso falso. In Italia e in UE, la titolarità del diritto d’autore sul codice sorgente tende a rimanere in capo all’autore, salvo regole specifiche (ad esempio nel lavoro subordinato) e soprattutto salvo patti scritti chiari che trasferiscano i diritti.
I casi più frequenti riguardano: founder che hanno scritto codice prima della costituzione della società, freelance a partita IVA, software house esterne e dipendenti sviluppatori. Se manca una catena di titolarità, porzioni di repository, pipeline CI/CD e documentazione possono risultare di terzi o con licenze limitate, anche se la roadmap prodotto dipende interamente da quei componenti.
La regola operativa nelle checklist di fundraising è netta: far firmare un IP assignment a ogni founder, dipendente e contractor prima che scrivano una sola riga di codice. Il motivo è ridurre al minimo l’incertezza sulla titolarità, includendo la cessione di asset creati prima dell’incorporazione e il lavoro svolto da contractor esterni.
3. Contratto di sviluppo software: quali clausole servono per trasferire correttamente i diritti
Un contratto di sviluppo software standard non basta se non disciplina in modo espresso la titolarità e gli oggetti da trasferire. Un IP assignment efficace deve coprire almeno: codice sorgente, repository, documentazione tecnica (API docs, architettura), dataset e modelli AI (pesi, prompt, pipeline di training), oltre al diritto di modifica e creazione di opere derivate.
La clausola chiave è la definizione del work product (risultati dell’attività) e la sua attribuzione alla società, includendo deliverable intermedi (branch, script, test, infrastructure-as-code). Serve anche una disciplina delle librerie di terzi (third-party components) con obbligo di disclosure e approvazione.
Per il controllo in due diligence, gli investitori cercano assignment con un perimetro sufficientemente ampio e tracciabile: deve essere chiaro chi ha contribuito al prodotto, cosa ha creato e in base a quale accordo. Quando serve un supporto contrattuale integrato con operazioni corporate, è importante che le competenze in proprietà intellettuale e in diritto societario lavorino in sinergia per allineare contratti, cap table e garanzie.
| Clausola | Cosa copre | Rischio se manca | Prova utile in due diligence |
|---|---|---|---|
| Definizione “Work Product” | Codice, script, test, docs | Ambiguità su cosa è ceduto | Allegato deliverable + accesso repo |
| Cessione dei diritti | Copyright e opere derivate | L’autore mantiene i diritti | IP assignment firmato |
| Consegna sorgenti e repo | Git history, chiavi, CI/CD | Vendor lock-in | Accessi amministrativi documentati |
| Disclosure third-party e OSS | Librerie e licenze | Copyleft inatteso | SBOM + lista dipendenze |
| Garanzia di non violazione | IP di terzi | Claim e indennizzi | Warranties + indennità |
| Diritti su dataset e modelli AI | Training data, pesi, prompt | Limitazioni d’uso commerciale | Allegati sulla provenienza dei dati |
4. Open source: quando accelera il prodotto e quando diventa un rischio
L’open source software (OSS) non è un problema in sé: è una leva di velocità e qualità, come dimostrano Linux, PostgreSQL e TensorFlow. Il punto è che ogni licenza (MIT, Apache-2.0, GPL, AGPL) impone obblighi diversi su distribuzione, notice, disclosure del sorgente e compatibilità. In due diligence, l’OSS viene valutato come rischio contrattuale e di go-to-market, non come giudizio tecnico.
Una buona pratica è eseguire un open-source audit già in fase pre-seed per identificare le esposizioni, in particolare le dipendenze GPL e AGPL. La mappatura può essere fatta con una SBOM (Software Bill of Materials) e con policy interne su pull request e dependency management.
Per la governance, conta anche la regola contrattuale: ogni contractor dovrebbe firmare un IP assignment prima di iniziare a lavorare. Se un contractor introduce una dipendenza AGPL in un componente core, la società può trovarsi a dover rilasciare i sorgenti o riprogettare l’architettura. Brevetti, marchi e segreto industriale restano strumenti complementari di tutela che rafforzano la posizione IP della startup.
5. Le 7 aree che una due diligence investitori controlla sulla proprietà intellettuale
In una due diligence seed o Series A, la proprietà intellettuale viene controllata in modo sistematico perché determina la difendibilità e la trasferibilità del business. Un diligence folder ordinato accelera la review: dovrebbe contenere tutti gli accordi IP firmati, per verificare la titolarità in modo rapido e trasparente.
| Area di controllo | Cosa chiede l’investitore | Red flag tipica |
|---|---|---|
| Catena di titolarità | Assignment da founder e contractor | Codice pre-incorporazione non ceduto |
| Contratti di sviluppo | Work product, sorgenti, repo | Solo licenza d’uso limitata |
| Open source | Audit licenze + SBOM | GPL o AGPL nel core |
| Dipendenze da terzi | API, SDK, cloud | Termini non trasferibili in M&A |
| Contestazioni IP | Diffide, claim, contenziosi | Nessuna disclosure o risposte incoerenti |
| Marchi e brand | Ricerche di anteriorità e depositi | Nome prodotto non liberabile |
| Coerenza cap table e asset | L’IP è della società, non delle persone | IP in capo a founder non allineato all’equity |
Queste aree riflettono le best practice consolidate in materia di assignment precoci e gestione degli asset creati da contractor.
6. Dipendenti, founder, consulenti e software house: chi deve firmare cosa e in quale momento
Founder, dipendenti, consulenti e software house non sono equivalenti sul piano documentale. Il principio pratico è costruire una catena di titolarità completa e continua, dalla pre-incorporazione fino ai rilasci in produzione. La best practice è che ogni founder firmi un IP assignment al momento dell’incorporazione, prima che inizi lo sviluppo.
Per i dipendenti, oltre a NDA e clausole di riservatezza, serve un’invention assignment compatibile con il contratto di lavoro e con le policy interne. Per i contractor la regola è ancora più netta: l’IP assignment va firmato prima di iniziare a lavorare.
Per software house e fornitori serve una sequenza precisa:
- NDA.
- Contratto di sviluppo con work product e consegna dei sorgenti.
- Dichiarazione sulle librerie di terzi.
- Garanzie di non violazione e manleva.
- Handover degli accessi (repository, cloud, CI/CD).
Questa sequenza riduce il rischio che parte del prodotto resti ostaggio del vendor.
7. IP assignment, licenza o cessione parziale: tabella comparativa per scegliere la struttura corretta
La scelta tra IP assignment (cessione piena), licenza (diritto d’uso) e cessione parziale (perimetro limitato) dipende dal modello di business e dallo scenario di exit. Per un prodotto SaaS destinato a venture capital, la preferenza quasi sempre è l’assignment: riduce l’incertezza nei round successivi e in M&A. Per progetti enterprise o di co-sviluppo, la licenza può essere sensata se mantiene riusabilità e IP core nella società.
| Struttura | Chi resta titolare | Quando usarla | Impatto su investitori e M&A |
|---|---|---|---|
| IP assignment (cessione piena) | Società | Core product, SaaS, AI | Massima pulizia in due diligence |
| Licenza esclusiva | Autore o terzo | Co-sviluppo con partner | Accettabile se irrevocabile e trasferibile |
| Licenza non esclusiva | Autore o terzo | Tool interni, componenti accessori | Spesso red flag sul core IP |
| Cessione parziale o per perimetro | Mista | Moduli, mercati, territori | Richiede definizioni molto precise |
| Dual licensing OSS | Società e community | Open core, monetizzazione enterprise | Serve una governance OSS solida |
8. Da dove partire per mettere in sicurezza i diritti sul software prima di fundraising o M&A
L’obiettivo è trasformare l’IP da conoscenza diffusa a dossier verificabile. L’implementazione completa di un IP assignment è tipicamente un lavoro da 1–2 mesi: partire subito evita blocchi in fase di term sheet e closing.
- Mappa gli asset: repository, documentazione, dataset, modelli AI, domini, marchi.
- Ricostruisci la catena di titolarità: chi ha scritto cosa, quando, con quale contratto (founder, dipendente, contractor, software house).
- Fai firmare i documenti mancanti: NDA, invention assignment, IP assignment, garanzie di non violazione, cessioni pre-incorporazione.
- Esegui un open-source audit: inventario di dipendenze e licenze, con focus su GPL e AGPL.
- Prepara il diligence folder: tutti gli accordi firmati e le prove di accesso ai repository.
Se l’operazione include M&A o venture capital, un supporto legale che integri IP, privacy e AI riduce gli attriti tra term sheet, representations & warranties e cap table. In OLegal lavoriamo proprio su questo incrocio tra proprietà intellettuale, M&A, venture capital, privacy e intelligenza artificiale, con un approccio orientato a trasparenza e rapidità operativa. Allineare il lavoro legale alle priorità di business significa tre cose: velocità di esecuzione, documentazione essenziale e riduzione dei rischi non tecnici che rallentano round e closing.
FAQ sull’IP assignment prima di un round
Quanto tempo serve per completare IP assignment e cartella di due diligence?
In media, completare l’IP assignment e mettere ordine nella documentazione richiede 1–2 mesi. La durata dipende da quanti contributor esterni hanno lavorato sul prodotto e da quanta documentazione manca. Se esiste già una mappa dei repository e dei contratti, spesso il lavoro si concentra nelle prime 2–3 settimane.
Posso raccogliere un seed round se parte del codice è stata scritta prima della costituzione della società?
Sì, ma serve una cessione scritta degli asset pre-incorporazione alla società e prove di consegna dei sorgenti e degli accessi ai repository. In assenza di documenti, gli investitori possono chiedere condizioni più onerose o rinviare il closing finché la catena di titolarità non è completa.
Come gestire i dataset usati per addestrare un modello AI in ottica di proprietà intellettuale?
Serve documentare provenienza, licenze e diritti d’uso dei dati, oltre alle regole di accesso e conservazione. Il dossier dovrebbe includere fonti, contratti con fornitori, eventuali restrizioni di riuso e policy interne. In due diligence, la tracciabilità del dataset pesa quanto la titolarità del codice.
Un investitore può bloccare l’operazione se trova una dipendenza AGPL nel core product?
Sì. Una dipendenza AGPL può imporre obblighi di disclosure del sorgente in certi scenari, creando un rischio commerciale e di exit. La soluzione tipica è sostituire la libreria, isolare il componente o cambiare architettura prima del closing. Un open-source audit anticipato evita sorprese.
Che differenza c’è tra NDA e IP assignment quando lavoro con una software house?
L’NDA protegge la riservatezza di informazioni e know-how, ma non trasferisce diritti sul software. L’IP assignment, o le clausole equivalenti nel contratto, serve a cedere alla società il copyright sul codice e sugli altri deliverable. Senza assignment, la software house può restare titolare anche se è stata pagata.
