Di chi è il codice della tua startup? La cessione dei diritti di sfruttamento dal socio alla società

È una delle sorprese più scomode di una due diligence: la startup sta costruendo il proprio prodotto da due anni, chiude un round di investimento, e nel rivedere la documentazione l'investitore scopre che la società non è proprietaria del proprio software. Non perché qualcuno l'abbia rubato, ma perché la proprietà intellettuale non è mai realmente passata all'azienda. E nella proprietà intellettuale, ciò che non viene ceduto per iscritto non è ceduto.

Il problema si presenta quasi sempre in tre situazioni: il fondatore che ha iniziato il progetto prima di costituire la società, il dipendente che programma il prodotto, e il freelance o l'agenzia che sviluppa su commissione. Tutte e tre si risolvono, ma bisogna farlo in tempo. Vediamole una per una.

Il punto di partenza che sorprende: la proprietà intellettuale nasce nella persona, non nell'azienda

Nel diritto spagnolo, l'autore è sempre la persona fisica che crea l'opera (art. 5 del testo unico della legge sulla proprietà intellettuale, TRLPI, RD Legislativo 1/1996). Una società non "crea" codice: lo creano le persone, ed è in quelle persone che nascono i diritti. L'azienda possiede solo ciò che le è stato effettivamente trasmesso. C'è inoltre una parte che non si trasmette mai: i diritti morali dell'autore sono irrinunciabili e inalienabili (art. 14 TRLPI), quindi ciò che si cede sono sempre i diritti di sfruttamento (riproduzione, distribuzione, elaborazione, comunicazione al pubblico), mai la paternità dell'opera in sé.

Scenario 1: il fondatore che ha iniziato prima della costituzione

È il caso più frequente e quello più spesso trascurato. Il fondatore sviluppa l'MVP, il marchio, il design o il primo codice quando è ancora una persona fisica, mesi prima di firmare l'atto costitutivo. Una volta costituita finalmente la società, dà per scontato che "il progetto" appartenga all'azienda. Non è così: la società è una nuova persona giuridica che non eredita automaticamente nulla di ciò che è stato creato prima della sua esistenza. Quella proprietà intellettuale resta del fondatore finché non la cede espressamente alla società.

Questo è esattamente ciò che risolviamo con un contratto di cessione dei diritti di sfruttamento dal socio alla società, e non è un formalismo: senza di esso, l'asset più prezioso della startup — la sua tecnologia — resta fuori dal bilancio dell'azienda e nelle mani di una persona fisica, con tutto ciò che comporta se quel socio se ne va, litiga o semplicemente non si presenta a firmare nel bel mezzo di un round di investimento.

Scenario 2: il dipendente

Per i lavoratori dipendenti la legge aiuta, ma conviene non fidarsi troppo. Per le opere generali create nell'ambito di un rapporto di lavoro, l'art. 51 TRLPI presume, in assenza di accordo scritto, che i diritti di sfruttamento siano ceduti in esclusiva al datore di lavoro, nella misura necessaria alla sua attività abituale. E per il software, ciò che qui conta di più, l'art. 97.4 TRLPI è più netto: quando un lavoratore dipendente crea un programma per elaboratore nell'esercizio delle proprie funzioni o seguendo le istruzioni dell'azienda, i diritti di sfruttamento del codice sorgente e del codice oggetto spettano esclusivamente al datore di lavoro, salvo patto contrario.

La sfumatura è duplice. Primo, questa attribuzione copre i diritti di sfruttamento, non quelli morali, e solo nell'ambito delle funzioni del lavoratore (ciò che un dipendente programma per conto proprio, al di fuori del suo ruolo, non rientra). Secondo, la presunzione legale è una rete di sicurezza, non un atto scritto: in una due diligence rigorosa, e soprattutto se occorre dimostrare la catena di titolarità a un investitore straniero, è molto meglio avere una clausola di cessione espressa in ogni contratto di lavoro piuttosto che affidarsi a una presunzione da spiegare.

Scenario 3: il freelance o l'agenzia (il più pericoloso)

Qui non c'è alcuna rete di sicurezza. Il regime degli artt. 51 e 97.4 si applica al rapporto di lavoro, non al lavoratore autonomo. Uno sviluppatore freelance o un'agenzia esterna che programma su commissione conserva la titolarità dei diritti di sfruttamento finché non li cede per iscritto, anche se hai pagato religiosamente ogni fattura. Pagare per un lavoro non equivale ad acquisirne la proprietà intellettuale. È lo scenario che crea più problemi, perché la startup crede di aver "comprato" lo sviluppo mentre in realtà ha solo pagato per riceverlo.

Come cedere correttamente (e perché la formulazione conta)

Il trasferimento dei diritti d'autore segue regole rigorose. Deve avvenire per iscritto (art. 43 TRLPI) e si interpreta in modo restrittivo: la cessione resta limitata alle modalità di sfruttamento espressamente previste e al tempo e ambito territoriale concordati. Una cessione vaga del tipo "cedo tutti i miei diritti" non è sufficiente. Un contratto ben redatto elenca le modalità (riproduzione, distribuzione, comunicazione al pubblico, elaborazione), il carattere esclusivo, il territorio e la durata, e include, nel caso del software, il codice sorgente, il codice oggetto e la documentazione associata, non solo il programma eseguibile.

Dal fondatore alla società: due vie, con un conto fiscale diverso

La cessione dal socio alla società può essere strutturata in due modi. Uno è un contratto di cessione (a titolo oneroso o gratuito), rapido e flessibile. L'altro è un conferimento in natura al capitale, in cui il socio conferisce la proprietà intellettuale in cambio di partecipazioni, il che richiede di valutare l'asset e comporta propri effetti societari. La scelta non è neutra dal punto di vista fiscale: il trasferimento può generare una plusvalenza nell'IRPF del socio per la differenza rispetto al valore di mercato, e se il socio controlla la società si tratta di un'operazione tra parti correlate da valutare a valore di mercato (art. 18 della Ley 27/2014 sull'imposta sulle società). Farlo per un euro "per semplificare" è esattamente ciò che un'ispezione fiscale mette poi in discussione.

Rischi che segnaliamo in rosso

Il primo, e quello che innesca tutto, è la due diligence di un round o di un'operazione di M&A: la titolarità della proprietà intellettuale è una delle dichiarazioni e garanzie (reps and warranties) richieste dall'investitore o dall'acquirente, e una lacuna in tal senso può bloccare l'operazione, ridurre la valutazione o trattenere parte del prezzo. Il secondo sono i freelance e le agenzie senza contratto di cessione, la falla più comune. Il terzo sono le cessioni redatte in modo così generico che l'interpretazione restrittiva le priva di effetto reale. E conviene ricordare che le invenzioni brevettabili dei dipendenti hanno un proprio regime (Ley 24/2015 sui brevetti), distinto da quello del diritto d'autore, quindi una startup deep tech deve considerare entrambi i livelli. È uno degli errori legali più comuni nel lanciare una startup.

Domande frequenti

Come la vediamo in Satya Legal

Nella maggior parte delle startup, la proprietà intellettuale è l'asset che sostiene la valutazione. Eppure è spesso l'ultima cosa a essere messa in ordine, quasi sempre di fretta e sotto la pressione di un round. Noi preferiamo il contrario: chiudere la catena di titolarità fin dall'inizio, con la cessione dal socio alla società firmata e i contratti di dipendenti e freelance dotati della propria clausola di cessione, nell'ambito della nostra consulenza alle startup, affinché quando arriva l'investitore non ci sia nessuna sorpresa da spiegare.