{"id":1233,"date":"2026-08-27T09:17:54","date_gmt":"2026-08-27T09:17:54","guid":{"rendered":"https:\/\/www.occhiutolegal.it\/?post_type=blog&p=1233"},"modified":"2026-08-27T09:17:54","modified_gmt":"2026-08-27T09:17:54","slug":"ip-assignment-startup-prima-del-round","status":"publish","type":"blog","link":"https:\/\/www.occhiutolegal.it\/en\/blog\/ip-assignment-startup-prima-del-round\/","title":{"rendered":"Come sistemare la propriet\u00e0 intellettuale prima del primo round: guida completa all’IP assignment per startup e imprese tech"},"content":{"rendered":"\n
\n \n

Come sistemare la propriet\u00e0 intellettuale prima del primo round: guida completa all’IP assignment per startup e imprese tech<\/h1>\n \n
\n

Prima di un round seed o Series A, la propriet\u00e0 intellettuale \u2014 codice, repository, documentazione tecnica, dataset e modelli AI \u2014 deve avere una catena di titolarit\u00e0 chiara e documentata a favore della societ\u00e0. Senza IP assignment e clausole corrette nei contratti, il software pu\u00f2 restare di propriet\u00e0 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.<\/p>\n <\/div>\n \n

Ultimo aggiornamento: 27 agosto 2026<\/p>\n \n

1. Perch\u00e9 la propriet\u00e0 intellettuale deve essere sistemata prima del primo round<\/h2>\n \n

Sistemare la propriet\u00e0 intellettuale prima del primo round non \u00e8 un esercizio formale: \u00e8 una condizione pratica per chiudere un investimento senza ritardi. Investitori \u2014 business angel<\/strong>, fondi seed<\/strong> e Series A<\/strong> \u2014 chiedono prove che la societ\u00e0 possieda davvero il copyright<\/strong> sul software e i diritti su asset come dataset e modelli AI.<\/p>\n \n

Le checklist operative di fundraising sono chiare: l’IP assignment<\/strong> \u00e8 un’azione pre-seed, con una tempistica tipica di 1\u20132 mesi. Nella pratica, la mancanza di una catena di titolarit\u00e0 chiara blocca la due diligence<\/strong> o impone condizioni sfavorevoli come escrow<\/strong>, indemnity<\/strong> o carve-out<\/strong>.<\/p>\n \n

Nel contesto UE, la propriet\u00e0 intellettuale include marchi, brevetti, diritto d’autore e diritti connessi: un perimetro ampio che va presidiato fin dall’inizio. Per le startup italiane \u00e8 utile incrociare questi requisiti con la compliance prevista per le startup innovative.<\/p>\n \n

Il punto che vediamo pi\u00f9 spesso nel nostro lavoro con startup tech \u00e8 che l’IP non \u00e8 un tema legale: \u00e8 un asset finanziario che deve essere trasferibile, auditabile e difendibile.<\/p>\n \n

2. Chi possiede davvero il codice, il prodotto e i dati se manca un IP assignment?<\/h2>\n \n

Senza un IP assignment, il presupposto “il software \u00e8 della societ\u00e0 perch\u00e9 l’ha pagato” \u00e8 spesso falso. In Italia e in UE, la titolarit\u00e0 del diritto d’autore sul codice sorgente<\/strong> 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.<\/p>\n \n

I casi pi\u00f9 frequenti riguardano: founder che hanno scritto codice prima della costituzione della societ\u00e0, freelance a partita IVA, software house esterne e dipendenti sviluppatori. Se manca una catena di titolarit\u00e0, porzioni di repository, pipeline CI\/CD<\/strong> e documentazione possono risultare di terzi o con licenze limitate, anche se la roadmap prodotto dipende interamente da quei componenti.<\/p>\n \n

La regola operativa nelle checklist di fundraising \u00e8 netta: far firmare un IP assignment a ogni founder, dipendente e contractor prima che scrivano una sola riga di codice. Il motivo \u00e8 ridurre al minimo l’incertezza sulla titolarit\u00e0, includendo la cessione di asset creati prima dell’incorporazione e il lavoro svolto da contractor esterni.<\/p>\n \n

3. Contratto di sviluppo software: quali clausole servono per trasferire correttamente i diritti<\/h2>\n \n

Un contratto di sviluppo software standard non basta se non disciplina in modo espresso la titolarit\u00e0 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.<\/p>\n \n

La clausola chiave \u00e8 la definizione del work product<\/strong> (risultati dell’attivit\u00e0) e la sua attribuzione alla societ\u00e0, includendo deliverable intermedi (branch, script, test, infrastructure-as-code). Serve anche una disciplina delle librerie di terzi (third-party components<\/strong>) con obbligo di disclosure e approvazione.<\/p>\n \n

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, \u00e8 importante che le competenze in propriet\u00e0 intellettuale e in diritto societario lavorino in sinergia per allineare contratti, cap table e garanzie.<\/p>\n \n

\n \n \n \n \n
Clausola<\/th>\n Cosa copre<\/th>\n Rischio se manca<\/th>\n Prova utile in due diligence<\/th>\n <\/tr>\n <\/thead>\n
Definizione “Work Product”<\/td>Codice, script, test, docs<\/td>Ambiguit\u00e0 su cosa \u00e8 ceduto<\/td>Allegato deliverable + accesso repo<\/td><\/tr>\n
Cessione dei diritti<\/td>Copyright e opere derivate<\/td>L’autore mantiene i diritti<\/td>IP assignment firmato<\/td><\/tr>\n
Consegna sorgenti e repo<\/td>Git history, chiavi, CI\/CD<\/td>Vendor lock-in<\/td>Accessi amministrativi documentati<\/td><\/tr>\n
Disclosure third-party e OSS<\/td>Librerie e licenze<\/td>Copyleft inatteso<\/td>SBOM + lista dipendenze<\/td><\/tr>\n
Garanzia di non violazione<\/td>IP di terzi<\/td>Claim e indennizzi<\/td>Warranties + indennit\u00e0<\/td><\/tr>\n
Diritti su dataset e modelli AI<\/td>Training data, pesi, prompt<\/td>Limitazioni d’uso commerciale<\/td>Allegati sulla provenienza dei dati<\/td><\/tr>\n <\/tbody>\n <\/table>\n <\/div>\n \n

4. Open source: quando accelera il prodotto e quando diventa un rischio<\/h2>\n \n

L’open source software<\/strong> (OSS) non \u00e8 un problema in s\u00e9: \u00e8 una leva di velocit\u00e0 e qualit\u00e0, come dimostrano Linux, PostgreSQL e TensorFlow. Il punto \u00e8 che ogni licenza (MIT<\/strong>, Apache-2.0<\/strong>, GPL<\/strong>, AGPL<\/strong>) impone obblighi diversi su distribuzione, notice, disclosure del sorgente e compatibilit\u00e0. In due diligence, l’OSS viene valutato come rischio contrattuale e di go-to-market, non come giudizio tecnico.<\/p>\n \n

Una buona pratica \u00e8 eseguire un open-source audit<\/strong> gi\u00e0 in fase pre-seed per identificare le esposizioni, in particolare le dipendenze GPL e AGPL. La mappatura pu\u00f2 essere fatta con una SBOM<\/strong> (Software Bill of Materials) e con policy interne su pull request e dependency management.<\/p>\n \n

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\u00e0 pu\u00f2 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.<\/p>\n \n

5. Le 7 aree che una due diligence investitori controlla sulla propriet\u00e0 intellettuale<\/h2>\n \n

In una due diligence seed o Series A, la propriet\u00e0 intellettuale viene controllata in modo sistematico perch\u00e9 determina la difendibilit\u00e0 e la trasferibilit\u00e0 del business. Un diligence folder<\/strong> ordinato accelera la review: dovrebbe contenere tutti gli accordi IP firmati, per verificare la titolarit\u00e0 in modo rapido e trasparente.<\/p>\n \n

\n \n \n \n \n
Area di controllo<\/th>\n Cosa chiede l’investitore<\/th>\n Red flag tipica<\/th>\n <\/tr>\n <\/thead>\n
Catena di titolarit\u00e0<\/td>Assignment da founder e contractor<\/td>Codice pre-incorporazione non ceduto<\/td><\/tr>\n
Contratti di sviluppo<\/td>Work product, sorgenti, repo<\/td>Solo licenza d’uso limitata<\/td><\/tr>\n
Open source<\/td>Audit licenze + SBOM<\/td>GPL o AGPL nel core<\/td><\/tr>\n
Dipendenze da terzi<\/td>API, SDK, cloud<\/td>Termini non trasferibili in M&A<\/td><\/tr>\n
Contestazioni IP<\/td>Diffide, claim, contenziosi<\/td>Nessuna disclosure o risposte incoerenti<\/td><\/tr>\n
Marchi e brand<\/td>Ricerche di anteriorit\u00e0 e depositi<\/td>Nome prodotto non liberabile<\/td><\/tr>\n
Coerenza cap table e asset<\/td>L’IP \u00e8 della societ\u00e0, non delle persone<\/td>IP in capo a founder non allineato all’equity<\/td><\/tr>\n <\/tbody>\n <\/table>\n <\/div>\n \n

Queste aree riflettono le best practice consolidate in materia di assignment precoci e gestione degli asset creati da contractor.<\/p>\n \n

6. Dipendenti, founder, consulenti e software house: chi deve firmare cosa e in quale momento<\/h2>\n \n

Founder, dipendenti, consulenti e software house non sono equivalenti sul piano documentale. Il principio pratico \u00e8 costruire una catena di titolarit\u00e0 completa e continua, dalla pre-incorporazione fino ai rilasci in produzione. La best practice \u00e8 che ogni founder firmi un IP assignment al momento dell’incorporazione, prima che inizi lo sviluppo.<\/p>\n \n

Per i dipendenti, oltre a NDA<\/strong> e clausole di riservatezza, serve un’invention assignment<\/strong> compatibile con il contratto di lavoro e con le policy interne. Per i contractor la regola \u00e8 ancora pi\u00f9 netta: l’IP assignment va firmato prima di iniziare a lavorare.<\/p>\n \n

Per software house e fornitori serve una sequenza precisa:<\/p>\n \n

    \n
  1. NDA.<\/li>\n
  2. Contratto di sviluppo con work product e consegna dei sorgenti.<\/li>\n
  3. Dichiarazione sulle librerie di terzi.<\/li>\n
  4. Garanzie di non violazione e manleva.<\/li>\n
  5. Handover degli accessi (repository, cloud, CI\/CD).<\/li>\n <\/ol>\n \n

    Questa sequenza riduce il rischio che parte del prodotto resti ostaggio del vendor.<\/p>\n \n

    7. IP assignment, licenza o cessione parziale: tabella comparativa per scegliere la struttura corretta<\/h2>\n \n

    La scelta tra IP assignment<\/strong> (cessione piena), licenza<\/strong> (diritto d’uso) e cessione parziale<\/strong> (perimetro limitato) dipende dal modello di business e dallo scenario di exit. Per un prodotto SaaS<\/strong> destinato a venture capital, la preferenza quasi sempre \u00e8 l’assignment: riduce l’incertezza nei round successivi e in M&A. Per progetti enterprise o di co-sviluppo, la licenza pu\u00f2 essere sensata se mantiene riusabilit\u00e0 e IP core nella societ\u00e0.<\/p>\n \n

    \n \n \n \n \n
    Struttura<\/th>\n Chi resta titolare<\/th>\n Quando usarla<\/th>\n Impatto su investitori e M&A<\/th>\n <\/tr>\n <\/thead>\n
    IP assignment (cessione piena)<\/td>Societ\u00e0<\/td>Core product, SaaS, AI<\/td>Massima pulizia in due diligence<\/td><\/tr>\n
    Licenza esclusiva<\/td>Autore o terzo<\/td>Co-sviluppo con partner<\/td>Accettabile se irrevocabile e trasferibile<\/td><\/tr>\n
    Licenza non esclusiva<\/td>Autore o terzo<\/td>Tool interni, componenti accessori<\/td>Spesso red flag sul core IP<\/td><\/tr>\n
    Cessione parziale o per perimetro<\/td>Mista<\/td>Moduli, mercati, territori<\/td>Richiede definizioni molto precise<\/td><\/tr>\n
    Dual licensing OSS<\/td>Societ\u00e0 e community<\/td>Open core, monetizzazione enterprise<\/td>Serve una governance OSS solida<\/td><\/tr>\n <\/tbody>\n <\/table>\n <\/div>\n \n

    8. Da dove partire per mettere in sicurezza i diritti sul software prima di fundraising o M&A<\/h2>\n \n

    L’obiettivo \u00e8 trasformare l’IP da conoscenza diffusa a dossier verificabile. L’implementazione completa di un IP assignment \u00e8 tipicamente un lavoro da 1\u20132 mesi: partire subito evita blocchi in fase di term sheet e closing.<\/p>\n \n

      \n
    1. Mappa gli asset<\/strong>: repository, documentazione, dataset, modelli AI, domini, marchi.<\/li>\n
    2. Ricostruisci la catena di titolarit\u00e0<\/strong>: chi ha scritto cosa, quando, con quale contratto (founder, dipendente, contractor, software house).<\/li>\n
    3. Fai firmare i documenti mancanti<\/strong>: NDA, invention assignment, IP assignment, garanzie di non violazione, cessioni pre-incorporazione.<\/li>\n
    4. Esegui un open-source audit<\/strong>: inventario di dipendenze e licenze, con focus su GPL e AGPL.<\/li>\n
    5. Prepara il diligence folder<\/strong>: tutti gli accordi firmati e le prove di accesso ai repository.<\/li>\n <\/ol>\n \n

      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<\/strong> lavoriamo proprio su questo incrocio tra propriet\u00e0 intellettuale, M&A, venture capital, privacy e intelligenza artificiale, con un approccio orientato a trasparenza e rapidit\u00e0 operativa. Allineare il lavoro legale alle priorit\u00e0 di business significa tre cose: velocit\u00e0 di esecuzione, documentazione essenziale e riduzione dei rischi non tecnici che rallentano round e closing.<\/p>\n \n

      \n \n

      FAQ sull’IP assignment prima di un round<\/h2>\n \n
      \n

      Quanto tempo serve per completare IP assignment e cartella di due diligence?<\/h3>\n

      In media, completare l’IP assignment e mettere ordine nella documentazione richiede 1\u20132 mesi. La durata dipende da quanti contributor esterni hanno lavorato sul prodotto e da quanta documentazione manca. Se esiste gi\u00e0 una mappa dei repository e dei contratti, spesso il lavoro si concentra nelle prime 2\u20133 settimane.<\/p>\n <\/div>\n \n

      \n

      Posso raccogliere un seed round se parte del codice \u00e8 stata scritta prima della costituzione della societ\u00e0?<\/h3>\n

      S\u00ec, ma serve una cessione scritta degli asset pre-incorporazione alla societ\u00e0 e prove di consegna dei sorgenti e degli accessi ai repository. In assenza di documenti, gli investitori possono chiedere condizioni pi\u00f9 onerose o rinviare il closing finch\u00e9 la catena di titolarit\u00e0 non \u00e8 completa.<\/p>\n <\/div>\n \n

      \n

      Come gestire i dataset usati per addestrare un modello AI in ottica di propriet\u00e0 intellettuale?<\/h3>\n

      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\u00e0 del dataset pesa quanto la titolarit\u00e0 del codice.<\/p>\n <\/div>\n \n

      \n

      Un investitore pu\u00f2 bloccare l’operazione se trova una dipendenza AGPL nel core product?<\/h3>\n

      S\u00ec. Una dipendenza AGPL pu\u00f2 imporre obblighi di disclosure del sorgente in certi scenari, creando un rischio commerciale e di exit. La soluzione tipica \u00e8 sostituire la libreria, isolare il componente o cambiare architettura prima del closing. Un open-source audit anticipato evita sorprese.<\/p>\n <\/div>\n \n

      \n

      Che differenza c’\u00e8 tra NDA e IP assignment quando lavoro con una software house?<\/h3>\n

      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\u00e0 il copyright sul codice e sugli altri deliverable. Senza assignment, la software house pu\u00f2 restare titolare anche se \u00e8 stata pagata.<\/p>\n <\/div>\n \n <\/section>\n \n<\/article>\n\n\n\n