Tutela del software aziendale: guida pratica completa

Il software è spesso uno degli asset di maggior valore di un'azienda moderna. Eppure è anche uno degli asset peggio tutelati. Tipicamente lo si costruisce, lo si usa, lo si vende, senza nemmeno sapere chi ne è il titolare giuridico, come difenderlo da copie non autorizzate, come gestire i contributi di sviluppatori.

In questa guida vediamo come tutelare il software aziendale in modo completo: cosa protegge la legge, cosa serve fare in più, contratti essenziali, errori da evitare.

Cosa protegge la legge automaticamente

In Italia e UE il software gode di alcune protezioni di default, senza necessità di registrazione:

Diritto d'autore

Il software è considerato "opera dell'ingegno" tutelata dal diritto d'autore (L. 633/1941 e Direttiva 2009/24/CE).

Cosa è protetto:

• Codice sorgente
• Codice oggetto (compilato)
• Materiale preparatorio (specifiche, schemi)
• Manuali e documentazione

Cosa NON è protetto:

• Idee e principi sottesi
• Algoritmi in sé (solo l'espressione)
• Linguaggi di programmazione
• Interfacce in quanto tali (alcune sentenze ammettono parziale protezione UI specifiche)

Durata: tutta la vita dell'autore + 70 anni dalla sua morte.

Limitazioni del diritto d'autore automatico

La protezione esiste, ma:

• Devi poter provare la titolarità (chi ha scritto cosa, quando)
• Devi poter dimostrare l'originalità
• Devi poter quantificare il danno in caso di violazione

Senza prove solide, "essere protetti dalla legge" diventa difficile da far valere in pratica.

I 6 strumenti di tutela complementari

1. Deposito presso enti di registrazione

Anche se non obbligatorio, registrare il software presso enti specializzati (SIAE in Italia per software) crea data certa di paternità.

Costo: poche centinaia di euro. Beneficio: prova preferenziale in giudizio.

Quando farlo: per software strategici, prima di rilasci pubblici, prima di trattative cessione.

2. Versionamento con timestamp certi

Sistemi di versioning (Git con commit firmati, repository in piattaforme professionali) creano traccia temporale dettagliata.

Best practice:

• Repository centrale aziendale
• Backup off-site regolari
• Commit firmati con identità verificabile
• Conservazione storia completa

Beneficio: prova progressiva di sviluppo originale.

3. NDA (Non Disclosure Agreement)

Per chiunque acceda al codice o specifiche.

Da firmare con:

• Dipendenti
• Collaboratori freelance
• Fornitori esterni
• Partner che vedono il codice
• Clienti enterprise che valutano integrazioni

Cosa deve contenere:

• Definizione chiara di "informazione riservata"
• Obbligo di riservatezza con durata
• Limitazioni d'uso
• Penali in caso di violazione
• Clausola foro competente e legge applicabile

4. Contratti di sviluppo con cessione diritti

Il contratto più importante quando commissioni sviluppo.

Clausole essenziali:

• Cessione completa dei diritti patrimoniali al committente
• Esclusività della cessione
• Garanzia di originalità (no codice copiato da terzi)
• Garanzia di assenza di vizi e difetti
• Manleva per uso di componenti open source con licenze restrittive
• Consegna codice sorgente + documentazione completa

Errore frequentissimo: contratti di sviluppo che parlano di "consegna del software" senza specificare cessione diritti. Risultato: paghi 50.000€ e il developer resta proprietario.

5. Politica licenze open source

Se usi componenti open source, ogni licenza ha vincoli diversi.

Categorie:

• Permissive (MIT, BSD, Apache): uso libero anche commerciale
• Copyleft debole (LGPL, MPL): uso commerciale ok ma con vincoli su modifiche
• Copyleft forte (GPL, AGPL): vincoli pesanti, possono "contagiare" il tuo codice

Pratica essenziale:

• Inventario dei componenti open source usati
• Verifica licenze e compatibilità
• Documentazione attribuzioni richieste
• Audit periodico

Rischio se mal gestito: potresti dover rilasciare il tuo codice come open source, perdere proprietà.

6. Segreti industriali

Aspetti del software particolarmente strategici (algoritmi proprietari, formule, dati di training) possono essere tutelati come segreti industriali (D.Lgs. 30/2005).

Requisiti:

• Informazione segreta (non nota o accessibile facilmente)
• Avere valore economico per la segretezza
• Misure ragionevoli per mantenerle segrete

Misure pratiche:

• Accesso ristretto a personale autorizzato
• Cifratura dati sensibili
• NDA per chi accede
• Tracciamento accessi

Tabella tutele per tipo di asset

Il caso specifico del software sviluppato in-house

Software sviluppato da dipendenti della tua azienda.

Regola generale (in Italia): salvo patto contrario, i diritti patrimoniali sul software sviluppato dal dipendente nell'esecuzione delle proprie mansioni spettano al datore di lavoro.

Best practice contrattuale:

• Clausola esplicita nel contratto di lavoro
• Specifica sulle attività in scope
• Eventuali pattuizioni su attività extra-lavoro

Caveat: software sviluppato da dipendente FUORI dall'orario di lavoro e SENZA mezzi aziendali può restare di sua proprietà se non c'è clausola specifica.

Il caso del software sviluppato da terzi

Software commissionato a freelance o agenzie.

Regola generale: senza clausola esplicita di cessione, i diritti restano del developer.

Cosa devi avere nel contratto:

• Cessione totale dei diritti patrimoniali
• Esclusività
• Diritto di modificare e creare opere derivate
• Diritto di trasferire i diritti a terzi (per future cessioni d'azienda)
• Consegna codice sorgente + tutto il materiale preparatorio
• Garanzie di originalità e di legittimità delle componenti usate

Errori frequenti che distruggono valore

1. Contratti di sviluppo generici

"Sviluppo software gestionale" senza clausole IP. Default = developer proprietario.

Costo errore: rinegoziazione cessione anni dopo, possibili contenziosi.

2. Niente NDA con dipendenti

Dipendente esce, va dal competitor, porta conoscenze.

Costo errore: leak di vantaggio competitivo.

3. Open source non tracciato

Componenti GPL inserite nel codice senza accorgersene.

Costo errore: obbligo di rilasciare proprio software come open source.

4. Codice senza versionamento centrale

Sviluppatore lavora su laptop personale, fa commit nel suo Git personale.

Costo errore: perdita codice se developer scompare, niente prova di paternità.

5. Niente backup off-site

Repository solo on-premise. Disastro = perdita totale.

Fix: backup multipli, geograficamente distribuiti, testati periodicamente.

6. Acquisto azienda senza due diligence software

Compri startup, scopri dopo che il "loro" software è in realtà di un fornitore esterno.

Costo errore: rinegoziazione post-acquisto, eventualmente recesso da contratto.

Roadmap pratica

Mese 1: audit dei contratti esistenti (lavoro, sviluppo, fornitori, NDA).

Mese 2: redazione/aggiornamento template contratti per nuovi rapporti.

Mese 3: inventario open source nel codice + verifica licenze.

Mese 4: deposito SIAE/registrazione formale per software strategici.

Continuo: NDA per ogni nuovo accesso, versioning disciplinato, backup verificati.

Conclusione

Il software aziendale è un asset di valore solo se è chiaramente di tua proprietà e difendibile legalmente. Costruire codice senza tutela è come costruire una casa senza atto di proprietà: funziona finché nessuno la contesta.

Le aziende tech che vendono o cedono il proprio business hanno tutte una caratteristica: contratti IP impeccabili. La due diligence dell'acquirente smaschera istantaneamente le posizioni deboli, abbattendo la valutazione.

Tutelare il software costa molto meno che ricostruire diritti dopo. La differenza tra avere il proprio software difendibile o meno si gioca in poche pagine di contratto e poche settimane di audit. Investimento minimo, ritorno enorme in solidità del business.