Quando un’agenzia affida lo sviluppo di un sito web a un partner esterno, la domanda su chi possiede il codice prodotto non è teorica: è una questione che può determinare se l’agenzia può consegnare il sito al cliente, se può portare il progetto da un altro sviluppatore, e se può rivendicare il lavoro come proprio portfolio. In Italia, la risposta non è ovvia e dipende quasi interamente da cosa c’è scritto nel contratto, o da cosa non c’è scritto.
Noi di Blurr strutturiamo ogni collaborazione con NDA e clausole di proprietà intellettuale esplicite fin dal primo progetto. L’abbiamo imparato osservando cosa succede quando questi accordi mancano, e quello che succede non è mai neutro.
Cosa dice la legge italiana sulla proprietà intellettuale del software
In Italia il software è protetto dalla Legge sul Diritto d’Autore (L. 633/1941, modificata dal D.Lgs. 518/1992 per recepire la Direttiva CE 91/250). Il principio generale è che i diritti patrimoniali sul software appartengono all’autore che lo ha creato, salvo eccezioni specifiche.
L’eccezione più rilevante per le agenzie: se lo sviluppatore è un dipendente, il software creato nell’esercizio delle sue mansioni appartiene al datore di lavoro. Se invece lo sviluppatore è un libero professionista, una società esterna o un partner white label, i diritti restano in capo a chi ha scritto il codice, a meno che il contratto non dica esplicitamente il contrario.
Questo significa che in assenza di una clausola contrattuale specifica sulla cessione dei diritti, il codice sviluppato da un partner esterno appartiene formalmente al partner, non all’agenzia che ha commissionato il lavoro e pagato la fattura.
È una situazione che crea problemi reali. Un’agenzia di Verona che seguivamo ci ha raccontato di aver perso l’accesso completo al codice di un sito ecommerce sviluppato da un freelance con cui avevano collaborato per due anni. Il rapporto si era concluso male, il freelance non rispondeva più, e il codice era su un repository privato di sua proprietà. Il cliente chiedeva modifiche urgenti, l’agenzia non aveva modo di intervenire senza ricominciare da zero. Il contratto originale non menzionava la proprietà del codice. Ci sono voluti tre mesi e un accordo economico aggiuntivo per riottenere l’accesso ai file.
I tre scenari che le agenzie devono gestire
Scenario 1: l’agenzia sviluppa internamente per il cliente finale. Il codice è prodotto da dipendenti o collaboratori dell’agenzia stessa. In questo caso la proprietà dipende dal tipo di rapporto lavorativo. Con dipendenti a tempo indeterminato o determinato, il codice appartiene all’agenzia per legge. Con collaboratori autonomi (partita IVA, collaborazione occasionale), serve una clausola contrattuale esplicita di cessione dei diritti.
Scenario 2: l’agenzia usa un partner white label come Blurr. Il codice è sviluppato da un soggetto terzo. Senza clausole specifiche, i diritti restano al partner. La soluzione corretta è una clausola nel contratto di collaborazione che preveda la cessione automatica dei diritti patrimoniali sull’opera all’agenzia committente al momento del pagamento della fattura. Questo è lo standard che applichiamo in tutti i nostri accordi con le agenzie partner.
Scenario 3: l’agenzia cede il sito al cliente finale. Indipendentemente da chi ha sviluppato il codice, l’agenzia deve avere i diritti per poterli cedere al cliente. Se il contratto con il cliente include la consegna del codice sorgente come proprietà del cliente, l’agenzia deve assicurarsi di avere quei diritti prima di firmare. Molte agenzie promettono “il sito è tuo” senza aver regolato la questione a monte con lo sviluppatore.
Cosa deve contenere il contratto con il partner esterno
Una clausola di proprietà intellettuale efficace in un contratto di sviluppo web deve coprire tre aspetti distinti.
Cessione dei diritti patrimoniali. Il partner cede all’agenzia tutti i diritti patrimoniali sul codice prodotto nell’ambito della collaborazione, inclusi i diritti di riproduzione, distribuzione, modifica e sublicenza. La cessione diventa efficace al momento del pagamento integrale del corrispettivo.
Esclusione del portfolio. Il partner rinuncia al diritto di citare il progetto come proprio lavoro nel proprio portfolio, mostrare screenshot o descrizioni del sito su propri canali, o rivelare l’esistenza della collaborazione a terzi. Questo è il nucleo del white label: non solo il codice è dell’agenzia, ma anche la paternità dell’opera.
Restituzione degli accessi. Alla conclusione del progetto o della collaborazione, il partner è tenuto a consegnare tutti gli accessi (repository, credenziali hosting, pannelli di amministrazione) e a rimuovere eventuali copie del codice dai propri sistemi.
Senza questi tre elementi, anche un NDA ben scritto lascia zone grigie che possono diventare costose da gestire.
Come documentiamo nell’articolo sul NDA con un partner white label, la riservatezza e la proprietà intellettuale sono due aspetti distinti che richiedono clausole separate nello stesso contratto.
La questione dei temi e plugin di terze parti
Un aspetto che spesso crea confusione: il codice sviluppato custom appartiene all’agenzia (con le clausole corrette), ma i temi commerciali, i plugin premium e i framework di terze parti hanno licenze proprie che non possono essere cedute.
Bricks Builder, che usiamo come page builder standard su tutti i nostri progetti, ha una licenza per sito che appartiene a chi l’ha acquistata. WooCommerce è GPL e può essere liberamente distribuito. I plugin premium hanno licenze diverse: alcuni sono per sito, altri per sviluppatore, altri ancora per agenzia.
Quando si consegna un sito al cliente finale, è importante chiarire nel contratto quali componenti sono licenze dell’agenzia (che potrebbero non essere trasferibili) e quali sono licenze che il cliente deve acquistare autonomamente. Questo vale sia per i plugin che per eventuali font commerciali, librerie di icone o stock photo incluse nel design. Come spieghiamo nell’articolo sul contratto di sviluppo web, le clausole sulle licenze di terze parti sono tra quelle più spesso dimenticate nei contratti standard delle agenzie.
Cosa fare se non c’è un contratto scritto
La situazione più comune nelle collaborazioni informali è l’assenza di un contratto scritto. Si lavora sulla fiducia, si comunica via WhatsApp, si fattura e si consegna. Finché il rapporto funziona nessuno fa domande. Quando si rompe, le questioni di proprietà emergono nel momento peggiore.
In assenza di contratto, la legge italiana tende a proteggere l’autore materiale dell’opera, cioè chi ha scritto il codice. L’agenzia che ha commissionato e pagato il lavoro ha ragioni economiche per rivendicare la proprietà, ma non ha uno strumento legale diretto. La via giudiziale è lenta e costosa, e nel frattempo il sito del cliente è bloccato.
La soluzione pratica per le collaborazioni già avviate senza contratto è regolarizzare retroattivamente con un accordo scritto che entrambe le parti firmano. Non è la soluzione ideale, ma è molto meglio di niente. Per le collaborazioni nuove, il contratto va firmato prima di iniziare qualsiasi lavoro, non dopo.
Se stai strutturando il tuo processo di collaborazione con partner tecnici esterni e vuoi assicurarti che la proprietà intellettuale sia gestita correttamente fin dall’inizio, blurr.it/contatti/ è il punto di partenza. Blurr, studio WordPress white label con sede a Calliano (Trento), include clausole di cessione dei diritti e NDA strutturato in ogni accordo di collaborazione.
Domande frequenti
No, non automaticamente. Il cliente ha pagato un servizio, non necessariamente i diritti sul codice. Cosa il cliente possiede dipende da cosa c’è scritto nel contratto con l’agenzia. Se il contratto dice “consegniamo il sito e tutti i diritti relativi”, l’agenzia deve avere quei diritti da cedere. Se il contratto non lo specifica, il cliente ha il sito in uso ma non necessariamente i diritti per modificarlo con un altro fornitore senza il consenso dell’agenzia originale.
Il codice custom sviluppato specificamente per il progetto è tutelabile. I temi e plugin di terze parti hanno le proprie licenze indipendenti. La personalizzazione grafica e il design possono essere tutelati come opera dell’ingegno. Un sito costruito interamente con componenti standard senza personalizzazioni significative ha una tutela più debole rispetto a uno con sviluppo custom rilevante.
Dipende dalla licenza open source. Il codice GPL, come WordPress e WooCommerce, può essere liberamente modificato e distribuito. Altre licenze open source hanno restrizioni diverse. Il codice MIT è molto permissivo. Il codice AGPL ha vincoli sulla distribuzione di versioni modificate. Prima di usare librerie open source in un progetto commerciale, è buona pratica verificare che la licenza sia compatibile con l’uso previsto.
I sistemi di version control come Git mantengono una storia completa di chi ha scritto cosa e quando. I commit firmati con chiavi GPG aggiungono un ulteriore livello di autenticità. In assenza di repository Git, email, messaggi e fatture che documentano lo scambio di file e il pagamento possono costituire prova indiziaria. In una controversia formale, una perizia tecnica può analizzare il codice e attribuirne la paternità sulla base dello stile di scrittura e delle firme digitali presenti.