La creazione di software in azienda solleva questioni complesse su diritti d’autore, titolarità economica e margini di riutilizzo da parte di sviluppatori e imprese. Tra codice sorgente, open source, plugin e soluzioni cloud, la linea di confine tra ciò che appartiene al datore di lavoro e ciò che resta al programmatore non è sempre intuitiva. Comprenderla è essenziale per evitare contenziosi e impostare contratti chiari.
Qualificazione giuridica del software come opera dell’ingegno
Nel diritto d’autore il software è considerato a tutti gli effetti una opera dell’ingegno. Non è più visto solo come uno strumento tecnico, ma come un risultato creativo, al pari di un testo o di una composizione musicale. La protezione riguarda il codice sorgente, il codice oggetto e persino il materiale preparatorio necessario allo sviluppo, purché vi sia un minimo di creatività nelle scelte e nella struttura.
La componente interessante, dal punto di vista aziendale, è che il software resta protetto come diritto d’autore, non come brevetto, salvo casi particolari. Questo significa che sono tutelate le forme espressive (come il codice), non l’idea astratta alla base del programma. Due gestionali per magazzino possono coesistere, se sviluppati in modo autonomo.
Il titolare iniziale del diritto d’autore è, in linea generale, la persona fisica che crea il software. Tuttavia, quando l’attività creativa avviene nell’ambito di un rapporto di lavoro subordinato, la legge prevede il trasferimento automatico dei diritti di utilizzazione economica al datore di lavoro, entro certi limiti. Ed è qui che cominciano le frizioni tra sviluppatori e imprese.
Programmatore dipendente, team di sviluppo e coautoria interna
Nel contesto aziendale il software raramente è opera di un singolo. Team di sviluppo, scrum team, figure di analisi e UX designer contribuiscono alla stessa soluzione digitale. Da un punto di vista giuridico, quando i contributi si fondono in un risultato unitario, si entra nel terreno della coautoria.
Ogni sviluppatore che apporta un contributo creativo originale diventa coautore. Tuttavia, nel rapporto di lavoro dipendente, i diritti patrimoniali confluiscono di regola in capo al datore di lavoro, mentre i diritti morali (paternità dell’opera, diritto al nome) restano ai singoli. Nella pratica, la paternità raramente viene esposta nel prodotto finale, ma può essere rilevante in un contenzioso o nella carriera professionale.
Le cose si complicano con collaboratori esterni, consulenti o freelance integrati nel team interno. Se il contratto non disciplina in modo chiaro la cessione dei diritti, ci si può ritrovare con un software dove l’azienda non è pienamente titolare di tutto il codice. Un dettaglio che emerge solo quando si tenta una cessione d’azienda, una fusione o l’ingresso di un investitore, con audit legali molto puntuali sul perimetro dei diritti.
Codice sorgente, documentazione tecnica e titolarità dei diritti
Quando si parla di titolarità si pensa quasi sempre al codice sorgente, ma in azienda il patrimonio protetto è molto più ampio. Manuali interni, documentazione tecnica, specifiche funzionali, diagrammi UML, script di deployment e perfino alcuni fogli di calcolo complessi possono essere qualificati come opere dell’ingegno autonome.
Nella maggior parte dei casi, se il lavoro è svolto da dipendenti nello svolgimento delle mansioni, i diritti di sfruttamento economico su questi materiali spettano all’azienda. Il dipendente, però, conserva i diritti morali e, soprattutto, non perde le competenze e il know-how acquisiti. Sapere come progettare una certa architettura non è, di per sé, appropriato dal datore di lavoro.
Molto delicato è il tema dell’accesso al codice sorgente da parte del cliente. Nei progetti commissionati a software house esterne, il cliente spesso ottiene solo una licenza d’uso, non la titolarità del codice. Per avere il controllo pieno può essere necessaria una cessione specifica o la messa in escrow del codice, da attivare solo in casi di insolvenza o interruzione del servizio.
Software open source, fork aziendali e conflitti di licenza
L’uso di software open source dentro progetti aziendali è ormai la norma. Librerie, framework e componenti vengono integrati in applicazioni proprietarie con grande disinvoltura. Dal punto di vista giuridico, però, l’uso di codice con licenze copyleft (come la GPL) può far emergere obblighi inattesi.
Il problema si pone soprattutto quando l’azienda crea un fork interno di un progetto open source, lo modifica e lo integra in un prodotto commerciale. Alcune licenze impongono, in presenza di distribuzione del software, l’obbligo di rendere disponibili i codici modificati con la stessa licenza. In pratica, parte del valore aggiunto sviluppato internamente potrebbe dover essere rilasciato alla comunità.
La titolarità del nuovo codice creato dall’azienda non è esclusa: l’impresa resta autrice delle porzioni originali. Tuttavia, l’esercizio di questi diritti è limitato dalle condizioni di licenza del progetto originario. Se lo sviluppatore dipendente riutilizza in proprio, fuori dall’azienda, pezzi di quel codice open source ibridato con soluzioni interne, il rischio è un doppio contenzioso: violazione della policy aziendale e violazione della licenza open source, con possibili richieste di cessazione d’uso e rilascio del codice.
Portabilità delle competenze e obbligo di non concorrenza post
Alla cessazione del rapporto di lavoro emerge il nodo tra ciò che il programmatore può portare con sé e ciò che deve restare in azienda. Le competenze personali, l’esperienza, i pattern architetturali appresi sono in linea di massima liberamente riutilizzabili. Diverso è il caso del codice e delle soluzioni specifiche progettate per l’impresa.
Il dipendente non può copiare repository, riutilizzare blocchi di codice sorgente identici o riprodurre pedissequamente la stessa applicazione per un concorrente. Anche senza clausole particolari, agire in questo modo può integrare violazione del diritto d’autore e dell’obbligo di fedeltà, almeno per il periodo in cui il rapporto è in vita.
In aggiunta, le parti possono pattuire un patto di non concorrenza post contrattuale. Deve essere scritto, prevedere un corrispettivo economico, avere un limite di durata e un perimetro chiaro (settore, area geografica, funzioni). In ambito IT spesso viene calibrato su specifiche tecnologie o su un certo prodotto. Un programmatore potrebbe, per esempio, poter lavorare su app mobile generiche, ma non su soluzioni B2B verticali che competono direttamente con una piattaforma proprietaria dell’ex datore.
Gestione contrattuale di plugin, API e soluzioni cloud proprietarie
Nel modello cloud e nelle architetture a microservizi, la questione della titolarità si sposta anche su plugin, moduli estendibili e API. Molte aziende offrono una piattaforma base e consentono a clienti o partner di sviluppare componenti aggiuntivi. Chi è titolare del codice di questi plugin? E dei dati che transitano via API?
La risposta dipende in larga parte dai contratti. Se il plugin è sviluppato dal cliente con propri mezzi, di regola la titolarità del codice resta al cliente, mentre la piattaforma mantiene la proprietà dell’ambiente e delle interfacce. In altri casi il contratto prevede una cessione o una licenza esclusiva a favore del fornitore, che può così integrare le soluzioni migliori nel prodotto standard.
Per le API, la protezione può riguardare la documentazione, il naming, la struttura non banale dell’interfaccia. La logica di back-end, invece, resta segreto industriale del fornitore. In ambiente SaaS, spesso il cliente non vede mai il codice eseguito sui server, ma solo l’output e la configurazione. Un disequilibrio informativo che rende essenziale negoziare fin dall’inizio cosa accade in caso di migrazione, esportazione dei dati o sviluppo di integrazioni personalizzate da riutilizzare su altre piattaforme.
