Proprietà codice sorgente startup: checklist per founder
Contenuto generato con intelligenza artificiale e verificato da controlli automatici di qualità e fonti, senza revisione umana. Come funziona.
Proprietà codice sorgente startup: il problema che nessuno ti spiega
Hai pagato lo sviluppo del tuo software. È online, funziona, i primi utenti lo usano. Ma il codice sorgente è tuo? Se non hai un contratto con una clausola scritta di cessione, la risposta probabilmente è no. E questo è il primo errore sulla proprietà codice sorgente startup che vediamo ripetersi tra i founder non tecnici.
Il punto è semplice: in Italia, i diritti patrimoniali sul software nascono in capo a chi lo scrive, non a chi lo paga. Lo stabilisce la legge sul diritto d'autore applicata al software. Senza un atto scritto che trasferisca quei diritti alla tua società, il codice resta dello sviluppatore. Anche se l'hai finanziato interamente tu.
Questo articolo è una checklist operativa. Copre tutti gli asset tecnici che devi intestare alla società prima che diventino un problema: in una due diligence, in un cambio di fornitore, in un conflitto con un co-founder tecnico che se ne va.
Cosa dice la legge italiana sul codice sorgente: chi è il proprietario
Il software è tutelato come opera dell'ingegno dalla legge sul diritto d'autore (L. 633/1941). Questo significa due cose concrete per un founder:
- Il diritto morale resta sempre allo sviluppatore: è il diritto di essere riconosciuto come autore. Non si può cedere.
- I diritti patrimoniali (usare, modificare, distribuire, vendere il software) possono essere ceduti, ma serve un contratto scritto.
Come spiega lo studio Canella Camaiora, il riparto dei diritti tra committente e sviluppatore dipende interamente da cosa prevede il contratto. Senza clausole esplicite, il committente ottiene solo una licenza d'uso, non la proprietà piena.
C'è un'eccezione importante: se il software è sviluppato da un dipendente nell'esecuzione delle sue mansioni, i diritti patrimoniali spettano al datore di lavoro, salvo patto contrario. Ma attenzione: questa regola non vale per i freelance, le software house esterne o i collaboratori a partita IVA. Per loro, serve sempre la cessione scritta.
Come evidenzia Cybersecurity360, disciplinare contrattualmente il destino del codice sorgente non è un dettaglio legale: è una scelta strategica che impatta sulla capacità dell'azienda di evolvere, manutenere e monetizzare il proprio prodotto.
Nota: per la redazione delle clausole contrattuali sulla proprietà del software, rivolgiti a un avvocato specializzato in IP e diritto d'autore. Questa checklist ti dice cosa verificare, non sostituisce una consulenza legale.
La checklist: asset tecnici da intestare alla società
Ecco la lista completa, divisa per categoria. Ogni voce ha un proprietario (chi deve risultare intestatario) e un'azione concreta.
1. Contratto e IP sul codice sorgente
| Asset | Intestatario | Azione |
|---|---|---|
| Contratto di sviluppo con clausola di cessione diritti patrimoniali | La società (SRL, non la persona fisica del founder) | Verifica che il contratto contenga una cessione esplicita, scritta, dei diritti di utilizzazione economica del software. Se non c'è, fai un addendum ora. |
| Clausola su codice preesistente e librerie | La società | Chiedi allo sviluppatore di dichiarare quali porzioni di codice sono preesistenti o open source, e con quale licenza. |
| Clausola su lavori derivati | La società | Il contratto deve chiarire che anche le modifiche future, le evoluzioni e i fork restano di proprietà della società committente. |
Esempio operativo: immagina di commissionare un MVP a una software house. Il contratto parla di "sviluppo e consegna dell'applicazione", ma non menziona la cessione dei diritti. Dopo sei mesi vuoi cambiare fornitore. La software house ti dice che il codice è suo e ti offre una licenza d'uso a canone annuale. Senza clausola di cessione, ha ragione lei.
2. Repository del codice
| Asset | Intestatario | Azione |
|---|---|---|
| Account dell'organizzazione sulla piattaforma di versionamento (es. GitHub, GitLab) | La società | Crea un'organizzazione intestata alla società. Il repo deve vivere lì, non nell'account personale dello sviluppatore. |
| Accesso admin al repository | Almeno due persone della società | Non lasciare mai un solo admin, soprattutto se è esterno. |
| Branch protection e regole di merge | La società decide le policy | Anche se non sei tecnico, assicurati che il branch principale sia protetto e che servano review per le modifiche. |
Il repository è la cassaforte del tuo prodotto. Se vive nell'account personale di un freelance, quel freelance può revocarti l'accesso in qualsiasi momento. Anche se il contratto dice che il codice è tuo, recuperarlo senza accesso al repo diventa una battaglia legale.
3. Account cloud e infrastruttura
| Asset | Intestatario | Azione |
|---|---|---|
| Account del cloud provider (AWS, Google Cloud, Azure) | La società, con fatturazione sulla società | Crea l'account con l'email aziendale. La carta di credito deve essere quella della società. |
| Accesso root/admin | La società | Lo sviluppatore lavora con un utente IAM dedicato, non con le credenziali root. |
| Ambiente di produzione | La società | Devi sapere dove gira il software, con quali risorse, e poter accedere in ogni momento. |
| Ambiente di staging/test | La società | Stesso discorso. Se lo sviluppatore usa il suo account per i test, quei dati sono fuori dal tuo controllo. |
4. Dominio, DNS e certificati
| Asset | Intestatario | Azione |
|---|---|---|
| Dominio | La società | Registralo tu, con il registrar che preferisci. Non lasciare che lo faccia il fornitore nel suo account. |
| Gestione DNS | La società | Devi avere accesso diretto. Se il fornitore gestisce i DNS nel suo pannello, chiedi il trasferimento. |
| Certificati SSL | La società | Con i certificati automatici (Let's Encrypt) il problema si riduce, ma verifica che siano configurati sul tuo account cloud. |
5. Servizi terzi e API
| Asset | Intestatario | Azione |
|---|---|---|
| Account per servizi di pagamento | La società | Il gateway di pagamento deve essere intestato alla società. Punto. |
| Account per servizi email transazionali | La società | Le email del tuo prodotto devono partire da un account tuo. |
| API key di servizi terzi | La società | Ogni chiave API usata nel progetto deve essere generata da un account intestato alla società. |
| Account analytics e monitoring | La società | I dati di utilizzo del prodotto sono tuoi. Non lasciarli nell'account del fornitore. |
6. Documentazione e credenziali
| Asset | Intestatario | Azione |
|---|---|---|
| Documentazione tecnica (architettura, API docs, schema DB) | La società | Chiedi che venga mantenuta nel repository, non in un documento separato accessibile solo al fornitore. |
| Password manager condiviso | La società | Usa un password manager aziendale. Le credenziali critiche non devono stare nella testa di una sola persona. |
| Credenziali dei database | La società | Sapere dove sono i dati, come accedere, come fare backup. |
Quando controllare: i tre momenti critici
Prima di firmare il contratto. La clausola di cessione dei diritti patrimoniali va negoziata prima, non dopo. È più facile e costa meno. Se un fornitore si rifiuta di cederti i diritti sul codice che stai pagando, è un segnale chiaro.
Al primo rilascio. Quando il software va in produzione, verifica che tutti gli account siano intestati alla società. Repository, cloud, dominio, servizi terzi. Se qualcosa è nel posto sbagliato, fallo spostare subito. Più aspetti, più diventa complicato.
Prima di un round di investimento. Gli investitori fanno (o dovrebbero fare) una due diligence tecnica. Una delle prime cose che controllano è la proprietà dell'IP. Se il codice non è chiaramente intestato alla società, il round si complica o salta. Non è un rischio teorico: è una delle ragioni più comuni per cui le due diligence si bloccano.
Per una panoramica sulle voci da verificare quando commissioni lo sviluppo, può essere utile anche la guida sul preventivo MVP: le voci da controllare.
Errori frequenti dei founder non tecnici
Confondere l'accesso con la proprietà
Avere le credenziali per fare login al pannello di controllo non significa possedere il codice. Puoi avere accesso a tutto e scoprire, il giorno in cui vuoi cambiare fornitore, che i diritti patrimoniali non sono mai stati trasferiti.
Fidarsi degli accordi verbali
Come chiarisce Brocardi.it, la cessione dei diritti di utilizzazione economica del software richiede la forma scritta. "Ce lo siamo detti" non regge in tribunale.
Intestare tutto al CTO o al co-founder tecnico
Se il co-founder tecnico lascia la società (succede), ogni asset intestato a lui diventa un problema. Repository, account cloud, domini: tutto deve essere intestato alla società come entità giuridica.
Ignorare le licenze open source
Il tuo software probabilmente usa librerie open source. Alcune licenze (come la GPL) hanno implicazioni sulla distribuzione del codice derivato. Chiedi allo sviluppatore un elenco delle dipendenze e delle relative licenze. Non è paranoia: è igiene tecnica.
Rimandare "perché ora il rapporto è buono"
I contratti servono per quando il rapporto smette di essere buono. Sistemare la proprietà degli asset tecnici quando c'è collaborazione e fiducia è semplice. Farlo durante un conflitto è costoso, lento e spesso impossibile.
Come si struttura un rapporto sano con chi sviluppa
La questione non è diffidare del fornitore. È costruire un rapporto dove entrambe le parti sanno cosa appartiene a chi.
Un fornitore serio non ha problemi a cedere i diritti sul codice commissionato. Se sviluppa il tuo MVP, sa che quel codice è stato pagato per risolvere il tuo problema specifico. La cessione dei diritti patrimoniali non gli toglie nulla: mantiene il diritto morale (la paternità dell'opera) e il know-how acquisito.
Quello che un fornitore può legittimamente voler trattenere sono le librerie e i framework proprietari sviluppati prima del tuo progetto e riutilizzabili su altri clienti. Questo è ragionevole, a patto che sia dichiarato nel contratto e che tu ottenga una licenza d'uso perpetua su quei componenti.
In Snoda, il metodo di lavoro prevede che la proprietà degli asset tecnici sia definita prima di scrivere la prima riga di codice. Non perché siamo diffidenti, ma perché chiarire subito evita problemi dopo. Chi sta valutando un MVP con budget ridotto dovrebbe mettere questo punto in cima alla lista delle priorità.
La checklist in sintesi
Stampala, mettila in un documento condiviso, usala come punto di partenza per la conversazione con il tuo fornitore o il tuo CTO.
- Contratto con clausola scritta di cessione diritti patrimoniali sul software
- Dichiarazione delle componenti preesistenti e open source
- Repository sotto organizzazione intestata alla società, con almeno due admin interni
- Account cloud intestato alla società, con fatturazione sulla società
- Dominio e DNS sotto account della società
- Tutti i servizi terzi (pagamenti, email, analytics, API) intestati alla società
- Documentazione tecnica accessibile e aggiornata nel repository
- Password manager aziendale con tutte le credenziali critiche
- Backup dei dati sotto il controllo della società
- Revisione periodica degli accessi (chi ha accesso a cosa, con quale ruolo)
Se hai un'idea di prodotto software e vuoi capire se è realizzabile — e con quali tempi e budget — puoi verificarlo in 90 secondi su Fattibile?, senza lasciare email e senza impegno. Se preferisci parlarne direttamente, c'è anche il contatto. Nel portfolio trovi esempi concreti di prodotti costruiti con questo approccio.
Domande frequenti
Chi è il proprietario del codice sorgente di un software commissionato?
In Italia, senza un contratto che dica il contrario, i diritti patrimoniali sul software restano allo sviluppatore che lo ha creato. Lo chiarisce la normativa sul diritto d'autore applicata al software. Per trasferirli alla società committente serve una clausola scritta esplicita di cessione dei diritti di utilizzazione economica.
Quali asset tecnici deve possedere una startup fin dal primo giorno?
Repository del codice sorgente, account cloud e infrastruttura, dominio e DNS, credenziali di servizi terzi (API, payment gateway, analytics), documentazione tecnica, ambienti di staging e produzione. Tutti intestati alla società, non a persone fisiche.
Come verifico che il codice sorgente sia intestato alla mia società?
Controlla tre cose: che il contratto con chi sviluppa preveda la cessione dei diritti patrimoniali, che il repository sia sotto un account intestato alla società, e che tu abbia accesso admin a tutti gli ambienti. Se manca anche solo uno di questi punti, intervieni subito.
Cosa rischio se il codice è intestato allo sviluppatore esterno?
Rischi di non poter modificare, rivendere o far evolvere il software senza il consenso dello sviluppatore. In caso di conflitto, potresti perdere l'accesso al prodotto che hai finanziato. In sede di due diligence per un round, un investitore noterà subito il problema. Come sottolinea Cybersecurity360, disciplinare il destino del codice sorgente è una scelta strategica, non un formalismo.
Il contratto deve essere scritto per trasferire i diritti sul software?
Sì. La legge italiana sul diritto d'autore richiede la forma scritta per la cessione dei diritti di utilizzazione economica del software. Un accordo verbale o una mail informale non bastano. Per la redazione delle clausole specifiche, affidati a un avvocato specializzato in proprietà intellettuale.
Questo articolo è stato generato da un sistema di intelligenza artificiale e sottoposto a un controllo automatico di qualità e di verifica delle fonti prima della pubblicazione, senza revisione editoriale umana. Informazione resa ai sensi dell'art. 50 del Regolamento (UE) 2024/1689 (AI Act). I contenuti hanno finalità informativa e non sostituiscono un parere professionale (legale, fiscale, finanziario o tecnico). Segnalazioni ed errori: scrivici. Dettagli su come usiamo l'AI.