Software e proprietà intellettuale

In Italia il codice software è normalmente protetto dal diritto d’autore. Il programma per elaboratore considerato in quanto tale non è brevettabile. Un’invenzione attuata mediante software può tuttavia essere brevettabile quando presenti un carattere tecnico e soddisfi i requisiti di novità, attività inventiva e applicazione industriale (art. 45 CPI). La valutazione richiede un’analisi brevettuale specifica.

Sono escluse dalla tutela autoriale le idee e i principi alla base degli elementi del programma, compresi quelli alla base delle interfacce, ai sensi dell’art. 2, n. 8, L. 633/1941. Restano invece tutelabili le forme espressive originali del programma, quali il codice sorgente e il codice oggetto. L’interfaccia grafica utente non beneficia necessariamente della tutela specifica riservata ai programmi, ma può essere protetta autonomamente dal diritto d’autore se originale.

I diritti esclusivi del titolare sono definiti dall’art. 64-bis: riproduzione, modificazione e distribuzione rientrano in generale nei suoi diritti esclusivi. La legge riconosce all’utente legittimo alcune facoltà: l’uso conforme alla destinazione e la copia di backup (art. 64-ter) e, a condizioni tassative, la decompilazione per interoperabilità (art. 64-quater) — consentita solo quando indispensabile per l’interoperabilità con un programma creato autonomamente, senza poter usare le informazioni per fini diversi, per un programma sostanzialmente simile o per violare il diritto d’autore. La tutela nasce con la creazione, senza formalità.

Per il software del dipendente vale l’art. 12-bis L. 633/1941: salvo patto contrario, il datore acquisisce i diritti esclusivi di utilizzazione economica del software creato nell’esecuzione delle mansioni o su sue istruzioni. Non basta però il solo fatto che l’autore sia dipendente: occorre verificare in concreto le mansioni affidate, le istruzioni ricevute e il collegamento tra attività lavorativa e programma realizzato. Restano distinti i diritti morali dell’autore.

Per il software commissionato a fornitore o freelance, il pagamento della fattura non basta, da solo, a dimostrare quali diritti siano stati trasferiti. L’esito dipende dal tipo di contratto, dal suo oggetto e dalle clausole su diritti di utilizzazione economica, codice sorgente, modifiche, opere derivate e documentazione. Per evitare contestazioni, il contratto dovrebbe disciplinare espressamente la titolarità o, almeno, l’estensione della licenza.

Quando il trasferimento avviene mediante cessione, la trasmissione deve essere provata per iscritto ai sensi dell’art. 110 L. 633/1941. Nei contratti di sviluppo è comunque opportuno disciplinare espressamente titolarità, licenza, consegna del sorgente e facoltà di modifica, senza affidarsi al solo pagamento del corrispettivo.

Gli obblighi delle licenze open source non sono automatici: dipendono dal testo della licenza, dalla versione, dalle modalità di incorporazione e dalla condotta (distribuzione, modifica, collegamento, messa a disposizione in rete). Le licenze permissive (MIT, BSD, Apache 2.0) impongono pochi obblighi (avviso di copyright, testo di licenza; Apache 2.0 aggiunge concessione di brevetto e file NOTICE) e non obbligano ad aprire il proprio codice. Nel copyleft forte (GPL v2/v3, AGPL) l’obbligo di rilascio dipende dalla qualificazione come opera derivata / lavoro combinato: rileva la distribuzione (conveyance), non la semplice esecuzione interna. L’AGPL ha una previsione specifica per il software modificato e messo a disposizione via rete, ma ciò non significa che ogni SaaS con un componente AGPL comporti l’apertura automatica dell’intero codice proprietario: vanno distinti uso separato, collegamento, incorporazione, modifica, comunicazione di rete e distribuzione. Il copyleft debole (LGPL, MPL 2.0) limita l’obbligo (LGPL consente linking dinamico da proprietario; MPL 2.0 copyleft solo sui file modificati). Non tutte le licenze si combinano (Apache 2.0 è incompatibile con GPLv2, compatibile con GPLv3): la contaminazione è il rischio di dover aprire codice proprietario integrato con componenti copyleft in un’opera derivata distribuita.

Nota: l’art. 64-quater L. 633/1941 (decompilazione per interoperabilità, v. sezione 1) non è una disciplina dell’open source: è materia diversa.

Il codice sorgente riservato è protetto come segreto commerciale ai sensi del CPI (D.Lgs. 30/2005), artt. 98-99, come modificati dal D.Lgs. 63/2018 (attuazione della Dir. UE 2016/943). L’art. 98 protegge le informazioni a tre condizioni cumulative: (a) segrete; (b) con valore economico perché segrete; (c) sottoposte a misure ragionevoli di segretezza.

Senza misure ragionevolmente adeguate, la tutela come segreto commerciale è esposta a venir meno. Le misure devono essere effettive e proporzionate al caso concreto: controllo degli accessi, segregazione dei repository, accordi di riservatezza, policy interne, logging e protezioni tecniche possono concorrere a dimostrarne l’adeguatezza. Non esiste un catalogo rigido: l’adeguatezza è valutata in concreto (dimensioni dell’impresa, tipo di informazione, numero di soggetti autorizzati). La mancanza dei requisiti degli artt. 98-99 non esclude necessariamente ogni tutela: possono residuare, quando ne ricorrano i presupposti, rimedi diversi come quelli in materia di concorrenza sleale.

Il marchio (nome dell’app o del software, logo) si registra presso UIBM (nazionale), EUIPO (UE) o in via internazionale (sistema di Madrid, WIPO). Non basta che il nome sia libero in senso generico. Verifica la capacità distintiva, l’assenza di impedimenti assoluti e l’assenza di marchi o altri segni anteriori confliggenti, tenendo conto dei prodotti e servizi interessati. L’elenco di prodotti e servizi va formulato con chiarezza e precisione (art. 156 CPI). Durata decennale rinnovabile (art. 48 Dir. UE 2015/2436). La registrazione è costitutiva del diritto esclusivo sul marchio registrato; esistono però anche diritti sul marchio non registrato derivanti dall’uso, con ambito e presupposti diversi.

Disegni e modelli. Non ogni interfaccia o icona è automaticamente un disegno/modello tutelabile: occorre che si tratti dell’aspetto esteriore di un prodotto o di una sua parte, che i requisiti (novità e carattere individuale) siano soddisfatti, con attenzione ai limiti da funzionalità tecnica. I diritti esclusivi su disegni e modelli sono collegati alla registrazione (art. 38 CPI). Per gli elementi grafici dell’interfaccia, se originali, può rilevare la tutela autoriale autonoma, distinta da quella del software.

La due diligence IP non verifica solo chi è titolare del codice, ma se e come la società può usarlo per il proprio business: se dispone di una licenza sufficiente per il modello di business; se la licenza è trasferibile in caso di acquisizione; se comprende modifica, sublicenza, distribuzione, uso in cloud e manutenzione; se il codice sorgente è effettivamente disponibile; se esistono componenti di terzi con licenze non trasferibili o obblighi incompatibili con l’operazione; se i contributi di dipendenti, consulenti e collaboratori sono coperti da una catena documentale coerente (chain of title).

Representations & warranties. Il venditore dichiara e garantisce piena titolarità o disponibilità dei diritti, assenza di violazioni IP di terzi, conformità open source e assenza di contenzioso, con indennizzi e, nei casi rilevanti, escrow del sorgente. Attenzione: una licenza d’uso può incontrare limiti di trasferimento nella cessione di azienda o ramo.