In sintesi
Chi riguarda: chi sviluppa o acquisisce software — founder, CTO, imprese tech — e deve mettere in sicurezza la proprietà intellettuale del codice.
Due usi: gestire il proprio IP (titolarità, licenze, segreti) e verificarlo in un’acquisizione (due diligence).
Riferimenti chiave: L. 633/1941 per il diritto d’autore sul software; CPI (D.Lgs. 30/2005) per segreti, marchi e brevetti.
Stato della norma: il software è protetto in via principale dal diritto d’autore; i segreti commerciali seguono gli artt. 98-99 CPI (D.Lgs. 63/2018, Dir. UE 2016/943). Il programma in quanto tale non è brevettabile, ma un’invenzione attuata mediante software può esserlo (art. 45 CPI). Testi vigenti da verificare su Normattiva ed EUR-Lex.
Mettere in sicurezza il codice, in quattro passi
Passo 1
Mappa autori, dipendenti e fornitori
Passo 2
Formalizza cessioni e licenze per iscritto
Passo 3
Inventaria le dipendenze open source
Passo 4
Proteggi segreti e marchi
I concetti chiave
Cosa è protetto
La forma espressiva del codice (sorgente e oggetto), non idee e principi, interfacce comprese (art. 2, n. 8).
Il codice del dipendente
Spetta al datore se creato nelle mansioni o su sue istruzioni (art. 12-bis); restano i diritti morali.
Il pagamento non basta
Pagare il freelance non prova il trasferimento: la cessione va provata per iscritto (art. 110).
Open source
Gli obblighi dipendono da licenza, versione e integrazione: con AGPL e SaaS niente conclusioni in astratto.
Segreti commerciali
Il sorgente riservato è tutelato solo con misure adeguate di segretezza (art. 98 CPI).
Marchio prima del lancio
Verifica disponibilità e anteriorità del segno: il dominio, da solo, non è un marchio.
I riferimenti normativi
Art. 64-bis
L. 633/1941 — diritti esclusivi
Art. 12-bis
L. 633/1941 — software del dipendente
Artt. 98-99
CPI — segreti commerciali
Art. 45
CPI — invenzioni via software
Licenze open source a confronto
| Profilo | Permissive (MIT, BSD, Apache 2.0) | Copyleft forte (GPL, AGPL) |
|---|
| Obblighi tipici | Avviso di copyright e testo di licenza; Apache 2.0 aggiunge brevetto e NOTICE | Rilascio del codice se c’è opera derivata distribuita |
| Aprire il proprio codice | Non richiesto | Dipende da opera derivata o lavoro combinato |
| Uso in SaaS | Nessun obbligo di apertura | AGPL: previsione specifica per l’uso via rete, da valutare caso per caso |
| Rischio tipico | Attribuzione mancante | Contaminazione del codice proprietario |
Titolarità: dipendente e fornitore esterno
Per il dipendente, salvo patto contrario, il datore acquisisce i diritti di utilizzazione economica del software creato nell’esecuzione delle mansioni o su sue istruzioni (art. 12-bis L. 633/1941): il collegamento tra mansioni e programma va verificato in concreto. Per il software commissionato a fornitore o freelance decide il contratto: titolarità o estensione della licenza, consegna del sorgente, modifiche e opere derivate. La cessione va provata per iscritto (art. 110). La registrazione SIAE non è costitutiva: può valere come elemento probatorio (art. 103).
Segreti, marchi e design
Il sorgente non pubblicato è segreto commerciale se segreto, dotato di valore economico perché segreto e protetto da misure ragionevoli (art. 98 CPI): accessi controllati, repository segregati, NDA, logging, valutati in concreto. Il marchio dell’app si registra presso UIBM, EUIPO o in via internazionale, con un elenco di prodotti e servizi chiaro e preciso (art. 156 CPI). Interfacce e icone possono essere disegni registrati se nuove e dotate di carattere individuale (art. 38 CPI) o, se originali, opere tutelate dal diritto d’autore.
Due diligence IP in un’acquisizione
Non basta sapere chi è titolare: la società deve disporre di una licenza sufficiente per il proprio modello di business e trasferibile nell’operazione, con modifica, sublicenza, uso in cloud e manutenzione; il sorgente deve essere disponibile; i contributi di dipendenti e collaboratori devono avere una catena documentale coerente (chain of title). Red flag: cessioni mancanti o generiche, licenze non trasferibili, obblighi copyleft incompatibili. Poi representations & warranties, indennizzi e, nei casi rilevanti, escrow del sorgente.
Approfondimenti ADLP
Domande frequenti su software e proprietà intellettuale
Il codice del mio freelance è mio?
Non automaticamente. Il pagamento della fattura, da solo, non prova quali diritti hai acquisito: conta il contratto (titolarità, licenza, sorgente, modifiche, opere derivate). Se il trasferimento avviene per cessione, serve prova scritta (art. 110). Disciplinalo espressamente.
Posso usare una libreria GPL o AGPL nel mio SaaS?
Dipende da testo e versione della licenza, componente, modifiche e integrazione. Con AGPL l’uso SaaS non consente, da solo, di concludere né che gli obblighi siano esclusi né che tutto il codice vada pubblicato. Caso per caso prima dell’integrazione.
Un dipendente può portarsi il codice?
Non senza autorizzazione. Se il software è stato creato nell’esecuzione delle mansioni o su istruzioni del datore, i diritti esclusivi di utilizzazione economica spettano al datore ai sensi dell’art. 12-bis; il dipendente conserva il diritto morale d’autore. Restano da verificare, caso per caso, side project, attività estranee alle mansioni e obblighi di riservatezza.
In un’acquisizione cosa chiedo prima di firmare?
Non solo la titolarità: licenza (se copre il modello ed è trasferibile), disponibilità del sorgente, componenti di terzi con obblighi incompatibili, chain of title su dipendenti e collaboratori; poi R&W, indennizzi, escrow.
Il nome dell’app lo posso proteggere?
Sì, come marchio (UIBM/EUIPO). Verifica capacità distintiva, disponibilità del segno e assenza di anteriorità prima del lancio; l’elenco di prodotti e servizi va formulato in modo chiaro e preciso.
Fonti
Guida in PDFScarica questa guida in PDF
Versione brandizzata da conservare o condividere. Lascia la tua email: ti diamo subito accesso al download.
