Download Word gratuito • Modifica online • Salva e condividi con Drive • Esporta in PDF
Un contratto di licenza del codice sorgente è un accordo legale bilaterale che regola l'accesso, l'uso, la manutenzione e la protezione del codice sorgente di un software. Questo modello Word gratuito e modificabile consente al detentore della proprietà intellettuale (concessore) di autorizzare una terza parte (concessionario) ad accedere al materiale del codice sorgente, mantenendo il controllo su come il codice può essere utilizzato, modificato e divulgato. Il contratto disciplina modalità di consegna del codice, gli usi consentiti (es. manutenzione, supporto, aggiornamenti), le restrizioni sulla divulgazione a terzi, gli obblighi di confidenzialità, e le procedure di distruzione del codice al termine della licenza. Puoi scaricarlo gratuitamente, modificarlo online o esportarlo in PDF per la stampa e la firma.
Senza un contratto di licenza del codice sorgente, il concessionario potrebbe utilizzare il codice in modo non autorizzato: sviluppare prodotti concorrenti, divulgare segreti commerciali, cedere la licenza a competitor, o trasferire il codice senza controllo. Questo contratto ti protegge da rischi di perdita di proprietà intellettuale, violazioni di confidenzialità e utilizzi impropri del tuo software. Inoltre, disciplina chiaramente quando il materiale deve essere consegnato, con quale documentazione, e quali sono gli obblighi di distruzione al termine della relazione commerciale, garantendo che il tuo vantaggio competitivo rimane protetto. Per aziende che vendono software con supporto personalizzato, partner di manutenzione, o clienti enterprise, questo documento è essenziale per strutturare una relazione professionale, trasparente e legalmente vincolante.
| Se la tua situazione è… | Usa questo modello |
|---|---|
| Concessione senza limiti di durata al concessionario, adatta a partner strategici a lungo termine. | Licenza perpetua non esclusiva |
| Licenza limitata a un numero di anni, ideale per contratti di manutenzione a progetto. | Licenza con scadenza temporale |
| Accesso esclusivo al codice limitato a una specifica area geografica o mercato. | Licenza esclusiva per territorio |
| Fornisci codice sotto licenza open source (MIT, GPL, Apache) mantenendo obblighi di attribuzione. | Licenza open source con attribuzione |
| Deposito del codice presso terza parte neutrale, rilascio al concessionario se fornitore fallisce. | Source code escrow agreement |
Perché conta: Il concessionario potrebbe rivendicare accesso a versioni, moduli o documenti che non intendi fornire, o potrebbe ricevere accidentalmente informazioni sensibili non autorizzate.
Fix: Crea un Allegato (Tabella A) che elenca in dettaglio ogni file, versione, documentazione, e elementi esclusi (es. chiavi di sicurezza, dati di produzione).
Perché conta: Potrebbe sorgere controversia sulla tua facoltà di revocare la licenza e modificare i termini in caso di violazione.
Fix: Chiarire esplicitamente: 'Licenza non esclusiva' significa che il Concessore può concedere licenze identiche ad altri; aggiungi una sezione di 'Diritti e rimedi del Concessore' che preserva il diritto di revoca.
Perché conta: Il concessionario potrebbe divulgare il codice a freelancer, subfornitori o partner senza vincoli, perdendo il controllo sulla proprietà intellettuale.
Fix: Specifica che solo dipendenti e contractor con esplicito NDA (non-disclosure agreement) coerente possono accedere; richiedi lista nominativa.
Perché conta: Il concessionario potrebbe conservare versioni obsolete con difetti di sicurezza o vulnerabilità, o trasferirle a terzi involontariamente.
Fix: Inserisci obbligo di distruzione entro [NUMERO] giorni da ogni nuova consegna, con certificazione scritta di [NUMERO] funzionari del concessionario.
Perché conta: Potrebbero nascere contraddizioni (es. il contratto principale consente un uso che la licenza sorgente vieta), generando dispute e incertezza legale.
Fix: Allega il contratto di licenza principale come Tabella A e cita esplicitamente i termini coerenti nella sezione 'Considerato che'.
Perché conta: In caso di controversia, ciascuna parte potrebbe intentare causa in una giurisdizione diversa, aumentando i costi e l'incertezza.
Fix: Aggiungi una sezione finale 'Disposizioni generali' che specifica: giurisdizione (es. leggi della Repubblica Italiana), foro competente (es. Tribunale di Milano), e lingua del contratto (italiano).
In linguaggio semplice: Specifica i termini e i concetti utilizzati nel contratto, come Giorno Lavorativo, Consegna, Software concesso in licenza, Diritti di proprietà intellettuale, e Materiale del codice sorgente.
Per 'Materiale del Codice Sorgente' si intende una copia completa della versione del codice sorgente del Software concesso in Licenza in forma leggibile dalla macchina, una volta compilato, produrrà la versione del codice oggetto del Software concesso in Licenza, e tutta la relativa documentazione tecnica, diagrammi di flusso, layout d'input e output, dizionario dei dati, [come ragionevolmente richiesto dal Concessionario].
Errore comune: Non allineare le definizioni con il contratto di licenza principale, creando ambiguità su quale versione del software è coperta e quali documenti sono inclusi nella consegna.
In linguaggio semplice: Definisce i tempi, il luogo e le modalità di consegna del primo set completo del codice sorgente dal concessore al concessionario.
Entro [NUMERO] Giorni Lavorativi dalla ricezione di un ordine d'acquisto debitamente compilato dal Concessionario, il Concessore fornirà il Materiale del Codice Sorgente al Concessionario presso la sede del Concessore in [STATO/PROVINCIA] (la 'Consegna Iniziale').
Errore comune: Non specificare un termine chiaro di giorni lavorativi, generando ritardi e dispute sulla tempestività della consegna.
In linguaggio semplice: Regola gli aggiornamenti periodici del codice sorgente forniti dal concessore, a propria discrezione, per mantenere il materiale allineato alle nuove versioni del software.
A discrezione del Concessore, il Concessore fornirà al Concessionario un completo set aggiornato dell'allora in vigore Materiale del Codice Sorgente (la 'Consegna Successiva') presso gli uffici del Concessore in [STATO/PROVINCIA].
Errore comune: Non chiarire se la consegna successiva è obbligatoria o facoltativa, creando incertezza sull'accesso alle versioni aggiornate del codice.
In linguaggio semplice: Specifica che il concessionario sostiene integralmente le spese logistiche per il ritiro e il trasporto del codice sorgente presso i propri uffici.
Le spese di trasporto del Materiale del Codice Sorgente presso gli uffici del Concessionario saranno a carico esclusivo del Concessionario.
Errore comune: Non chiarire chi sostiene i costi di trasporto e assicurazione, generando contenziosi su oneri nascosti.
In linguaggio semplice: Obbliga il concessionario a cancellare e distruggere tutte le versioni precedenti del codice sorgente, conservando solo la versione più recente fornita, e a certificare per iscritto l'avvenuta distruzione.
Il Concessionario cancellerà e distruggerà tutti i nastri informatici, i dischi e altri supporti magnetici, e distruggerà tutto il materiale della Consegna precedente. Il Concessionario fornirà al Concessore un certificato redatto da [NUMERO] alti funzionari che attesti la distruzione di tutto il materiale.
Errore comune: Non prevedere l'obbligo di certificazione scritta della distruzione, rendendo impossibile verificare il rispetto della norma.
In linguaggio semplice: Definisce il tipo di licenza concessa (perpetua, personale, non esclusiva, non trasferibile) e lo scopo limitato dell'utilizzo (manutenzione e assistenza del software).
Il Concessore garantisce al Concessionario una licenza [perpetua], personale, non esclusiva e non trasferibile per l'utilizzo del Materiale del Codice Sorgente solo per la manutenzione e l'assistenza della versione del codice oggetto del Software concesso in Licenza per il proprio uso interno.
Errore comune: Concedere una licenza esclusiva quando si intende permettere licenze multiple, o viceversa; non distinguere chiaramente tra uso perpetuo e temporale.
In linguaggio semplice: Elenca esattamente quali operazioni il concessionario può svolgere sul codice: copie per la manutenzione, revisioni, ricompilazione, e divulgazione limitata a dipendenti e contractor.
La presente Licenza consente al Concessionario di: Effettuare copie del Materiale del Codice Sorgente necessarie per mantenere il Software; Effettuare revisioni del Materiale; Ricompilare il Software dal Materiale; Divulgare il Materiale soltanto a dipendenti [a tempo pieno] o [contraenti indipendenti] per il quale la divulgazione è necessaria per la manutenzione e l'aggiornamento del Software.
Errore comune: Non limitare esplicitamente gli usi consentiti, permettendo al concessionario di utilizzare il codice per scopi diversi da quelli autorizzati (es. sviluppo di prodotti concorrenti).
In linguaggio semplice: Vieta al concessionario di cedere, trasferire, sublicenziare o divulgare il codice sorgente a terzi al di fuori del perimetro autorizzato, proteggendo la proprietà intellettuale del concessore.
Il Concessionario accetta di utilizzare il Materiale del Codice Sorgente solo per il proprio utilizzo e soltanto agli scopi espressamente indicati. Qualsiasi divulgazione al di fuori dei limiti autorizzati è proibita e costituisce violazione del contratto.
Errore comune: Non vietare esplicitamente il trasferimento a competitor, fornitori alternativi o società affiliate, rischiando la perdita di vantaggio competitivo.
In linguaggio semplice: Impone al concessionario di trattare il codice come informazione riservata e confidenziale, implementando misure di sicurezza per prevenire accessi non autorizzati.
Il Concessionario si impegna a mantenere il Materiale del Codice Sorgente in regime di stretta confidenzialità, implementando misure di sicurezza fisica e digitale adeguate a impedire accessi non autorizzati, perdita, furto o divulgazione accidentale.
Errore comune: Non specificare standard di sicurezza concreti (es. crittografia, autenticazione multifactore, audit trail), rendendo difficile provare il rispetto della confidenzialità.
In linguaggio semplice: Stabilisce le modalità di risoluzione della licenza, l'obbligo di restituzione o distruzione del codice al termine, e gli effetti sulla continuità del supporto.
Al termine del presente Contratto, il Concessionario cesserà immediatamente l'utilizzo del Materiale del Codice Sorgente e lo restituirà o distruggerà completamente entro [NUMERO] giorni, fornendo certificazione scritta della distruzione. Il Concessionario non avrà diritto a ulteriore supporto dal Concessore dopo la data di risoluzione.
Errore comune: Non definire chiaramente che cosa accade al codice e ai backup al termine della licenza, generando controversie sulla restituzione e sulla persistenza dei diritti.
Compila i campi [DATA], [IL NOME DELLA TUA IMPRESA], [STATO/PROVINCIA], [IL TUO INDIRIZZO COMPLETO] con i dati del concessore e [NOME DELL'IMPRESA], [INDIRIZZO COMPLETO] con i dati del concessionario. Utilizza la denominazione sociale esatta di ogni azienda e la sede legale.
💡 Copia i dati dal registro delle imprese (CCIAA, Registro del Commercio) per evitare errori di denominazione.
Sostituisci [NUMERO] nel paragrafo 2.1 con il numero di giorni entro cui il concessore fornirà il materiale (es. 10, 15, 30 giorni lavorativi). Scegli un termine realistico in base alle tue capacità organizzative.
💡 Se la consegna è complessa, richiedi 15-20 giorni lavorativi; per consegne semplici, 5-10 giorni sono sufficienti.
Nel paragrafo relativo alle definizioni, specifica esattamente quale versione del software e quale documentazione tecnica è inclusa: sorgente compilabile, eseguibile, file di configurazione, database, diagrammi, manuali, ecc. Usa la Tabella A o Allegati per elencare in dettaglio.
💡 Includi o escludi esplicitamente elementi sensibili (chiavi di sicurezza, credenziali, token API, dati di test) per evitare esposizioni accidentali.
Nel paragrafo 3, decidi se la licenza è perpetua (senza scadenza) o temporale (es. 1, 3, 5 anni). Scegli se esclusiva (solo il concessionario) o non esclusiva (puoi concederla anche ad altri). Di norma, per accordi di supporto, si usa non esclusiva e perpetua.
💡 La licenza perpetua è meno rischiosa se il concessionario è affidabile; usa scadenze temporali se vuoi mantenere leva negoziale o se il partner è nuovo.
Nel paragrafo 3.1, specifica che il codice può essere usato solo per manutenzione, supporto e aggiornamenti interno. Nel paragrafo 3.1(d), indica se la divulgazione è limitata a dipendenti a tempo pieno, contractor, o entrambi. Qualsiasi altro uso è vietato.
💡 Se il concessionario lavora con subappaltatori, permetti la divulgazione solo a contractor sottoposti a NDA (non-disclosure agreement) coerente.
Nel paragrafo 2.3, specifica il numero di alti funzionari (es. 2 firmatari) che devono certificare la distruzione del materiale precedente. Definisci chi redige il certificato (es. responsabile IT, CFO, legal) e con quale frequenza.
💡 Richiedi certificazioni scritte ogni volta che consegni una versione successiva, creando una traccia verificabile del rispetto dei tuoi diritti.
Se non incluso nel template, aggiungi una sezione che richieda al concessionario di implementare misure di sicurezza informatica (crittografia, autenticazione, audit log) proporzionali al valore del codice. Specifica come il concessionario gestirà accessi, backup e storage.
💡 Fai riferimento a standard riconosciuti (ISO 27001, NIST Cybersecurity Framework) per definire gli standard di sicurezza attesi.
Prima di inviare il contratto al concessionario, consulta un avvocato specializzato in diritto IT per adattarlo alla giurisdizione specifica (Italia, Svizzera-Ticino) e al contesto commerciale. Sottoscrivi da entrambe le parti con firma digitale qualificata o carta d'identità.
💡 Non trascurare questa revisione legale: i costi di una revisione anticipata sono minori rispetto ai danni da una violazione di proprietà intellettuale in seguito.
Una licenza di codice sorgente privata (come questo modello) è un accordo bilaterale tra il concessore e il concessionario, con controllo totale sugli usi, la divulgazione e le modifiche. Una licenza open source consente a chiunque di usare, modificare e ridistribuire il codice secondo i termini della licenza (es. GPL richiede che il codice derivato resti open source). Usa il modello privato se desideri mantenere il controllo; usa open source se il tuo modello di business si basa sulla comunità e sulla collaborazione esterna.
Sì, ma solo se il contratto lo prevede esplicitamente. Aggiungi una sezione 'Cause di risoluzione' che specifica: (a) violazioni material, (b) mancato pagamento (se applicabile), (c) insolvenza, (d) accesso non autorizzato. Prevedi un preavviso di [NUMERO] giorni per dare al concessionario la chance di rimediare. Dopo la revoca, il concessionario deve distruggere tutto il materiale entro [NUMERO] giorni.
Per default, il concessionario rimane titolare di eventuali modifiche che sviluppa con i propri mezzi. Se desideri acquisire proprietà sulle modifiche, aggiungi una clausola che richiede al concessionario di cedere o concedere una licenza gratuita al concessore su ogni modifica materiale. Negozia questo punto attentamente: molti concessionari resistono alla cessione totale e preferiscono mantenere diritti sulle loro innovazioni.
In Italia e Svizzera, non sono dovute imposte sulla concessione della licenza stessa se la licenza è non trasferibile e limitata a uso interno. Se ricevi corrispettivi economici (es. canone di licenza), questi sono redditi imponibili per il concessore e deducibili per il concessionario come costo. Consulta il tuo commercialista per l'analisi fiscale specifica della tua situazione.
Includi: codice sorgente compilabile, file di configurazione non sensibili, database schemi, diagrammi architetturali, manuali tecnici, script di build. Escludi esplicitamente: chiavi crittografiche, token API, credenziali di database produzione, dati di clienti finali, certificati SSL, configurazioni di sicurezza. Crea un documento di 'Esclusioni di sicurezza' che alleghi al contratto e aggiorna periodicamente.
Per default, la licenza termina. Se desideri proteggere il tuo codice in caso di fallimento/insolvenza, aggiungi una clausola che ordina al liquidatore di distruggere tutto il materiale entro [NUMERO] giorni. Altrimenti, puoi prevedere un 'Source Code Escrow': depositi il codice presso una terza parte neutrale, che lo rilascia al concessionario solo in caso di tuo fallimento o abbandono del progetto, garantendo continuità del supporto.
Sì, se la licenza è non esclusiva (come il modello). Il concessionario ha diritto al codice per la manutenzione, ma non al monopolio. Se desideri impedire al concessionario di sapere chi altri ha accesso, aggiungi una clausola di confidenzialità che vieta al concessionario di chiedere o divulgare a terzi l'identità di altri concessionari.
Per contratti di manutenzione/supporto, la licenza è generalmente perpetua (indefinita), finché il software è supportato. Se il supporto termina, la licenza termina. Alternativamente, puoi usare licenze temporali (1–5 anni) rinnovabili, che ti danno leva negoziale. Per software critico, molte aziende negoziano una 'perpetual license' con aggiornamenti terminati a una data specifica, permettendo al concessionario di mantenere l'ultima versione ricevuta in perpetuo.
Richiedi una certificazione scritta firmata da almeno 2 alti funzionari (es. CTO, CFO) che attesti la distruzione di tutti i supporti magnetici, dischi, backup e copie cartacee entro [NUMERO] giorni dalla risoluzione. Specifica che la certificazione deve includere: data, descrizione del materiale distrutto, metodo di distruzione (incenerimento, tritatura, formattazione sicura), e firma legale. Riservati il diritto di audit presso gli uffici del concessionario se necessario.
Un contratto di licenza software standard disciplina l'uso del software compilato (eseguibile) e non prevede accesso al codice sorgente. È adatto a clienti finali e utenti standard. Un contratto di licenza del codice sorgente estende il diritto a accedere, modificare e mantenere il codice sottostante, aggiungendo obblighi di confidenzialità, distruzione e limitazioni di divulgazione. Usa il contratto standard per clienti finali; usa il contratto di codice sorgente per partner di supporto e integratori.
Un accordo di escrow designa una terza parte neutrale (es. banca dati professionale) come custode del codice sorgente. Il codice rimane sequestrato finché il concessore è attivo; se il concessore fallisce o abbandona il progetto, l'escrow rilascia il codice al concessionario. Usa l'escrow se il concessionario vuole protezione contro il rischio di fallimento del fornitore; è più costoso ma offre certezza legale. Il contratto semplice fornisce accesso diretto e immediato, senza custode terzo.
Un NDA bilaterale protegge le informazioni sensibili scambiate tra le parti, incluso il codice sorgente. Tuttavia, un NDA non specifica diritti di licenza, usi consentiti, termini di consegna, o obblighi di distruzione. Un contratto di licenza del codice sorgente è più specifico e comprensivo: disciplina la proprietà, l'accesso, le modifiche, e la restituzione del codice. Puoi usare un NDA in parallelo per proteggere altri dati sensibili (roadmap, clienti, strategie).
Una licenza open source pubblica consente a chiunque di usare, copiare, modificare e ridistribuire il codice, con pochi vincoli (es. GPL richiede attribuzione e licenziamento derivato). Una licenza privata è ristretta e contrattuale: accesso limitato a soggetti specifici, modifiche vietate o vincolate, divulgazione proibita. Usa open source se il tuo modello di business si basa su collaborazione comunitaria; usa privata se il codice è competitivo e riservato.
Aziende che vendono software proprietario con supporto personalizzato devono regolamentare l'accesso al codice per clienti enterprise e partner di manutenzione.
Integratori e consulenti IT ricevono codice sorgente da fornitori per personalizzare soluzioni; questo contratto protegge il fornitore e disciplina l'uso.
Fornitori SaaS concedono accesso al codice sorgente a clienti enterprise come parte di SLA premium e obblighi di supporto.
Istituti finanziari richiedono accesso al codice sorgente di piattaforme di pagamento e trading per conformità normativa e audit periodici.
Piattaforme di vendita online forniscono codice sorgente a partner commerciali, rivenditori e integratori di sistemi di gestione inventario.
Software medico e farmaceutico è soggetto a normative stringenti (FDA, GDPR); fornitori concedono accesso a ospedali e cliniche per audit e conformità.
In Italia, il contratto è regolato dal Codice Civile (diritti d'autore: artt. 2575–2619) e dalla normativa sulla proprietà intellettuale (DPR 518/1972, legge 633/1941). Consulta un avvocato esperto di diritto dell'informatica per garantire conformità alle normative GDPR e sulla protezione dei dati in caso di accesso al codice contenente dati personali.
In Svizzera (Ticino), il contratto è regolato dal Codice Civile svizzero (artt. 956–1010) e dalla legge federale sulla protezione della proprietà intellettuale (LPI). La giurisdizione è il Tribunale di Lugano o il Tribunale federale. Nota: Svizzera non è membro UE; GDPR non si applica direttamente, ma la legge sulla protezione dei dati (DSG, entrata in vigore gennaio 2023) impone obblighi simili.
| Percorso | Ideale per | Costo | Tempo |
|---|---|---|---|
| Usa il modello | Accordi semplici con partner affidabili, startup con budget limitato, draft rapido da negoziare. | €0–50 (modello online) | 2–4 ore di compilazione autonoma |
| Modello + revisione legale | Accordi con partner strategici, software ad alto valore, esigenza di adattare il contratto a situazioni specifiche. | €150–400 (review legale superficiale) | 1–2 settimane (review + iterazioni) |
| Redatto su misura | Accordi complessi, software mission-critical, multinazionali, esigenza di protezione massima della proprietà intellettuale. | €1.000–3.000+ (drafting completo da avvocato) | 3–8 settimane (negoziazione + revisioni) |
Questo documento è uno dei 3,000+ modelli aziendali e legali inclusi in Business in a Box.
Accedi a oltre 3,000+ modelli aziendali e legali per qualsiasi attività, progetto o iniziativa.
Personalizza il tuo modello di documento aziendale pronto all'uso e salvalo nel cloud.
Condividi i tuoi file e cartelle con il tuo team. Crea uno spazio di collaborazione fluida.
"Idea fantastica! Non so come farei senza. Vale ogni centesimo, e come investimento si è ripagato più volte."
"Ho usato Business in a Box per 4 anni. È stata la fonte di modelli più utile che abbia mai trovato. Lo raccomando a chiunque."
"Mi ha salvato la vita così tante volte che ho perso il conto. Business in a Box mi ha fatto risparmiare tantissimo tempo e, come sapete, il tempo è denaro"
Smetti di scaricare documenti. Inizia a operare con chiarezza. Business in a Box ti offre il sistema operativo aziendale utilizzato da oltre 250.000 aziende in tutto il mondo per strutturare, gestire e far crescere la tua attività.
Piano gratuito per sempre · Nessuna carta di credito richiesta
