Licenze software: cosa sapere prima di avviare un progetto

Proprietà del codice, licenze d'uso, open source, SaaS e continuità operativa: una guida pratica per affrontare un progetto software con maggiore consapevolezza.

In sintesi

• Pagare un progetto software non significa automaticamente avere pieni diritti su ogni sua componente.
• Proprietà del codice, licenza d'uso e accesso al codice sorgente sono aspetti distinti, e vanno chiariti separatamente.
• "Open source" non significa "senza regole": ogni licenza ha obblighi diversi, e la differenza tra uso interno e distribuzione è centrale.
• Nel SaaS la domanda chiave non è "di chi è il software", ma cosa accade ai dati, all'export e alla continuità operativa.
• Framework, plugin, librerie, contenuti e componenti di terze parti possono convivere nello stesso progetto e vanno dichiarati con chiarezza.
• Una buona licenza non irrigidisce il rapporto: protegge entrambe le parti e dà al progetto un perimetro entro cui crescere.

In questo articolo

• L'equivoco più comune
• Proprietà, licenza d'uso e accesso al codice non sono la stessa cosa
• Le principali famiglie di licenze software
• La zona grigia dei progetti reali
• Cosa dovrebbe chiedere il cliente prima di iniziare
• Cosa dovrebbe chiarire il fornitore
• Domande frequenti
• La licenza come parte dell'architettura del software
• Per approfondire

L'equivoco più comune

Quando si commissiona un software, un gestionale, una piattaforma web, un sito evoluto, un'applicazione su misura, la conversazione iniziale si concentra quasi sempre sulle stesse tre cose: cosa deve fare, quanto costa, quando sarà pronto. Sono domande sacrosante, ma da sole non bastano.

Manca quasi sempre una quarta domanda, almeno altrettanto importante:

Una volta consegnato, cosa potrò davvero farne?

È una domanda che molti clienti non si pongono, perché danno per scontata la risposta. Il ragionamento implicito è semplice: "ho pagato, quindi è mio, quindi posso farci quello che voglio". Da qui nasce un equivoco molto diffuso, ed è alla base della maggior parte dei conflitti che, anni dopo, sorgono tra cliente e fornitore.

In realtà, aver pagato lo sviluppo di un software non significa automaticamente avere pieni diritti su ogni sua componente. A seconda del contratto, della licenza, della natura del progetto e dei componenti utilizzati, alcuni aspetti possono cambiare in modo significativo:

• usare il software senza limiti di tempo, sedi o utenti;
• modificarlo liberamente o farlo modificare da un altro fornitore;
• ottenere il codice sorgente e una documentazione utile a manutenerlo;
• installarlo su un'altra infrastruttura o su un altro cloud;
• riutilizzarlo per altre aziende del proprio gruppo;
• rivenderlo o distribuirlo come prodotto proprio;
• interrompere il rapporto con il fornitore senza compromettere la continuità operativa.

Non si tratta di scenari teorici. Sono le situazioni con cui qualunque azienda, prima o poi, si confronta: un cambio di fornitore, una migrazione di infrastruttura, un'acquisizione, l'ingresso di nuovi soci, un'espansione su altre sedi, la chiusura del rapporto con chi ha sviluppato il sistema. In tutti questi casi, ciò che è scritto (o non scritto) nella licenza diventa improvvisamente molto concreto.

La risposta a "cosa potrò farne dopo?" dipende da diversi fattori intrecciati: il contratto firmato, la licenza scelta, la natura del software, gli eventuali componenti open source, i framework proprietari del fornitore, le piattaforme terze coinvolte, le librerie commerciali integrate, le clausole specifiche di cessione o concessione dei diritti.

Per questo, in un progetto software, non basta chiedere "quanto costa?". Bisogna chiedere anche "cosa potrò farne dopo?". E la risposta, idealmente, dovrebbe arrivare prima di firmare, non quando il progetto è già in produzione e il rapporto è già strutturato.

Chiarire questi aspetti non è un eccesso di formalismo, né un atto di diffidenza. È un investimento sulla solidità del progetto. Una buona licenza non serve a complicare il rapporto tra cliente e fornitore: serve a evitare equivoci, a proteggere entrambe le parti e a garantire che il software possa evolvere nel tempo senza diventare un nodo difficile da sciogliere.

Proprietà, licenza d'uso e accesso al codice non sono la stessa cosa

Una buona parte degli equivoci nei progetti software nasce da quattro concetti che vengono spesso confusi: proprietà del codice, licenza d'uso, accesso al codice sorgente e manutenzione. Sono cose diverse, regolate in modo diverso e con conseguenze pratiche diverse. Tenerle distinte è il primo passo per capire cosa si sta davvero comprando, e cosa si sta davvero vendendo.

Proprietà del codice

La proprietà del codice riguarda chi detiene i diritti patrimoniali sul software: in pratica, chi può autorizzarne modifica, distribuzione, rivendita o concessione in licenza ad altri.

Per impostazione predefinita, in molti ordinamenti, chi scrive il codice ne detiene i diritti. Questo significa che, in assenza di accordi diversi, anche un software pagato dal cliente potrebbe rimanere, almeno in parte, di proprietà del fornitore o degli sviluppatori che lo hanno realizzato.

Perché i diritti patrimoniali passino al cliente serve una cessione esplicita, scritta nel contratto. E anche in quel caso, la cessione non è quasi mai totale: di solito riguarda solo le parti sviluppate su misura, mentre librerie, framework, componenti riutilizzabili e strumenti di sviluppo restano governati dalle proprie licenze.

In altre parole: avere la proprietà del codice custom non significa avere la proprietà di tutto ciò che fa funzionare il software.

Licenza d'uso

La licenza d'uso è il diritto di utilizzare il software entro certi limiti, senza necessariamente esserne proprietari. È lo schema più diffuso: il fornitore mantiene la proprietà, il cliente riceve il permesso di usare il software secondo regole concordate.

Quei limiti possono riguardare molti aspetti diversi:

• durata: licenza perpetua o a tempo determinato;
• ambito: una sede, un'azienda, un gruppo di società, un territorio;
• dimensione: numero di utenti, di postazioni, di server, di transazioni;
• finalità: uso interno, uso commerciale, rivendita;
• modalità tecniche: installazione on-premise, accesso cloud, distribuzione a terzi.

Una licenza d'uso può essere ampia o restrittiva, esclusiva o non esclusiva, trasferibile o personale. Due contratti possono parlare entrambi di "licenza d'uso" e voler dire cose molto diverse. È per questo che leggere i dettagli, o farli leggere a chi è in grado di interpretarli, non è un eccesso di prudenza, ma una parte normale del lavoro.

Accesso al codice sorgente

Avere il codice sorgente significa avere a disposizione i file leggibili e modificabili che compongono il software. È una condizione tecnicamente necessaria per poter intervenire sul sistema, capirlo, manutenerlo o farlo evolvere con un altro fornitore.

Ma, ed è il passaggio più frainteso, disporre del codice non implica automaticamente il diritto di farne tutto ciò che si vuole.

Un cliente può avere il sorgente per ragioni di continuità operativa (poter intervenire in caso di emergenza, garantire la manutenzione, prevenire situazioni di blocco) e al tempo stesso non avere il diritto di rivendere quel software, di distribuirlo a terzi o di usarlo come base per un prodotto proprio. Sono dimensioni separate: l'accesso tecnico è una cosa, i diritti d'uso sono un'altra.

Per questo, nei contratti seri, il diritto di accesso al codice viene di solito regolato in modo specifico: a chi viene consegnato, in quale momento, con quale documentazione di accompagnamento, per quali finalità, con quali eventuali limiti di utilizzo.

Una soluzione possibile, spesso ragionevole, è quella in cui il fornitore consegna il codice sorgente per finalità di manutenzione e continuità, ma mantiene i diritti commerciali sulle parti non specifiche del progetto: framework, librerie interne, componenti riutilizzabili.

Manutenzione e continuità operativa

L'ultimo livello, spesso sottovalutato, è quello operativo: chi può intervenire sul software dopo la consegna, e a quali condizioni.

La manutenzione non è solo una questione tecnica. Ha una dimensione contrattuale (chi è autorizzato a intervenire sul codice), una dimensione pratica (chi ha la documentazione, gli ambienti di sviluppo, le credenziali, gli strumenti di build e deploy) e una dimensione di conoscenza (chi conosce abbastanza il sistema da poterci lavorare in tempi ragionevoli).

Un software può essere formalmente di proprietà del cliente, con sorgente consegnato e licenza ampia, ma essere di fatto manutenibile solo dal fornitore originario, perché la documentazione è scarsa, le scelte tecniche non sono spiegate, gli ambienti di sviluppo non sono replicabili, le dipendenze non sono dichiarate.

È il caso del cosiddetto lock-in operativo: una situazione in cui, sulla carta, il cliente ha tutti i diritti, ma nella pratica non ha le condizioni per esercitarli. È un rischio reale e va affrontato non solo a livello di licenza, ma anche di consegna tecnica: documentazione, istruzioni di deploy, elenco delle dipendenze, accessi alle infrastrutture, procedure di backup e ripristino.

Quattro livelli da tenere insieme

Vale la pena fissare un'idea: proprietà, licenza, accesso al codice e manutenzione sono quattro livelli distinti, e un progetto software ben impostato li affronta tutti, in modo esplicito.

Confonderli, o lasciarne alcuni impliciti, è ciò che genera, anni dopo, le situazioni più complicate: clienti convinti di possedere qualcosa che non possiedono, fornitori convinti di aver concesso meno di quanto effettivamente concesso, sistemi che nessuno può davvero modificare, migrazioni impossibili, contenziosi evitabili.

Chiarire questi quattro livelli all'inizio del progetto non è un appesantimento burocratico. È il modo più semplice per evitare che, con il passare del tempo, una scelta tecnica diventi un problema relazionale.

Le principali famiglie di licenze software

Esistono molti modi di concedere, o non concedere, diritti su un software. Le pagine che seguono non sono un catalogo esaustivo, ma una mappa dei modelli che un cliente incontra più di frequente nei progetti reali. Per ciascuno proviamo a fare due cose: spiegare in sintesi di cosa si tratta dal punto di vista tecnico e contrattuale, e poi guardarlo dal punto di vista pratico del cliente.

L'obiettivo non è classificare i modelli in "buoni" e "cattivi". Ogni modello ha la sua logica, i suoi vantaggi e le sue conseguenze. Capirli aiuta a scegliere consapevolmente, non a diffidare a priori.

Software proprietario

Parte tecnico-legale

Nel modello proprietario, il fornitore mantiene la proprietà del software e concede al cliente un diritto d'uso secondo regole definite dal contratto. Il cliente non acquista il software in senso stretto: ottiene, a fronte di un pagamento iniziale o periodico, la possibilità di utilizzarlo.

Le forme concrete sono diverse: una licenza perpetua con un pagamento iniziale, un canone periodico, una licenza legata al numero di utenti o di postazioni, un contratto che combina più elementi. In molti casi sono previsti aggiornamenti, manutenzione e supporto, spesso vincolati alla continuità del rapporto contrattuale.

Gli aspetti che vanno chiariti, in un contratto proprietario, sono diversi:

• perimetro d'uso: quante installazioni, quanti utenti, quali sedi, quali finalità;
• modifiche: se il cliente può intervenire sul software o se questo è riservato al fornitore;
• dipendenza dal fornitore: per aggiornamenti, correzioni, supporto, evoluzioni;
• durata e rinnovo: cosa succede se il canone non viene rinnovato, se il contratto termina, se il fornitore cambia politica commerciale;
• livello di personalizzazione: stiamo parlando di un prodotto standard, di una sua configurazione, o di uno sviluppo personalizzato che si appoggia a una base proprietaria?

Quest'ultimo punto è particolarmente importante. Un software proprietario "puro" è un prodotto pensato per essere uguale per tutti i clienti, con margini di configurazione. Un software proprietario "personalizzato" è invece un sistema costruito su misura, ma realizzato sopra una base tecnologica che resta del fornitore. Le due cose hanno conseguenze contrattuali molto diverse.

Nei panni del cliente

La prima domanda da porsi, davanti a un'offerta su base proprietaria, è semplice: sto comprando un prodotto, una sua configurazione o uno sviluppo su misura che lo estende?

La risposta cambia tutto. Se sto comprando un prodotto standard, è ragionevole che il fornitore mantenga proprietà e controllo: sto pagando per usare qualcosa che esiste già, e che continuerà a evolvere indipendentemente da me. Se invece sto commissionando un lavoro su misura, un'integrazione complessa, un modulo dedicato, una personalizzazione importante, è legittimo chiedersi cosa accade a quella parte specifica: chi la possiede, chi può modificarla, cosa succede se in futuro voglio farla mantenere da qualcun altro.

Le altre domande utili sono di natura operativa: cosa succede se il software non viene aggiornato per anni? E se il fornitore cambia listino? E se viene acquisito o cessa l'attività? E se le mie esigenze cambiano e ho bisogno di una funzione che il prodotto standard non prevede?

Il modello proprietario non è di per sé un problema. È un modello solido, su cui si reggono moltissimi software professionali. Ma comporta una dipendenza strutturale dal fornitore, che va valutata con lucidità: in alcuni contesti è un vantaggio (il fornitore investe nel prodotto, lo evolve, ne garantisce la qualità), in altri è un vincolo da bilanciare con clausole di continuità, diritti di intervento in caso di cessazione del rapporto o forme di deposito del codice presso un soggetto terzo.

Cessione dei diritti patrimoniali

Parte tecnico-legale

Nella cessione dei diritti patrimoniali, il cliente non riceve solo una licenza d'uso: acquisisce i diritti economici sul codice sviluppato e può esercitarli nei limiti previsti dalla cessione. È il modello che molti clienti immaginano, in modo implicito, quando pensano di "aver pagato lo sviluppo".

In pratica, però, una cessione dei diritti funziona solo se è scritta in modo chiaro nel contratto. Senza una clausola esplicita, il cliente potrebbe ottenere, a seconda del contesto giuridico e del tipo di rapporto, soltanto un diritto d'uso, anche se ampio. La cessione non è un effetto automatico del pagamento: è un atto contrattuale specifico.

I parametri da chiarire sono diversi:

• oggetto della cessione: cosa esattamente viene ceduto (codice custom? documentazione? configurazioni?);
• esclusività: la cessione è esclusiva o non esclusiva? Il fornitore può riutilizzare le stesse soluzioni per altri clienti?
• territorio e durata: la cessione vale ovunque e per sempre, o ha limiti?
• diritti specifici trasferiti: uso, modifica, distribuzione, rivendita, concessione in licenza a terzi;
• componenti escluse: parti preesistenti del fornitore, librerie open source, framework di base, strumenti di sviluppo, componenti di terze parti.

L'ultimo punto è quello che genera più malintesi. Anche una cessione molto ampia, in pratica, non può cedere ciò che il fornitore stesso non possiede: una libreria open source resta governata dalla sua licenza, un componente commerciale di terze parti resta soggetto al suo contratto, un framework proprietario del fornitore può essere concesso in uso ma non trasferito in proprietà. Una cessione, per quanto generosa, riguarda di solito il codice originale prodotto per il progetto, non l'intero stack tecnologico che lo fa funzionare.

Nei panni del cliente

Se il contratto prevede una cessione dei diritti patrimoniali, è importante leggerla per quello che è davvero, senza né sopravvalutarla né svalutarla.

Da un lato, è un risultato significativo: il cliente acquisisce diritti reali su una parte del software, può farlo evolvere con altri fornitori, può integrarlo in altri sistemi, può, entro i limiti previsti, riutilizzarlo o trasferirlo. È un livello di autonomia che il modello puramente proprietario non offre.

Dall'altro lato, una cessione non rende il cliente padrone dell'intero sistema. Il software consegnato è quasi sempre composto anche da parti che il fornitore non ha scritto, e che continuano a vivere sotto le proprie regole: librerie open source con i loro obblighi, plugin commerciali con le loro licenze, framework con i propri vincoli, servizi cloud con i propri contratti.

Le domande utili da porsi, in questo caso, sono operative:

• la cessione riguarda solo il codice custom o anche le sue componenti accessorie (script, configurazioni, documentazione)?
• il fornitore ha il diritto di riusare lo stesso codice per altri clienti?
• quali componenti del progetto non sono stati ceduti, e perché?
• se in futuro voglio rivendere o distribuire il software, ci sono vincoli derivanti dalle componenti di terze parti?
• ho ricevuto, insieme al codice, anche le informazioni necessarie per gestirlo (documentazione, dipendenze, ambienti di sviluppo)?

Una cessione ben scritta non si limita a dichiarare "i diritti sono ceduti": precisa cosa è ceduto, cosa non lo è, e su quali basi. È nelle eccezioni, più che nelle dichiarazioni di principio, che si misura la qualità del contratto.

SaaS / Software as a Service

Parte tecnico-legale

Il modello SaaS rovescia molte delle premesse dei due precedenti. Nel SaaS, il cliente normalmente non riceve il software: accede a un servizio erogato dal fornitore attraverso un'infrastruttura, di solito tramite browser o API. Il software gira su server gestiti dal provider, e il cliente paga per poterlo utilizzare, tipicamente con un abbonamento.

In questo schema, il tema della proprietà del codice passa normalmente in secondo piano rispetto alle condizioni di accesso al servizio, alla gestione dei dati e alla continuità operativa. Il codice non è installato presso il cliente, e nella maggior parte dei casi il cliente non lo vedrà mai. La domanda rilevante non è "di chi è il software", ma "cosa succede ai miei dati e alla mia operatività".

Gli aspetti che vanno chiariti in un contratto SaaS sono numerosi, e raramente sono tutti scritti nello stesso documento:

• modalità di accesso: utenti, ruoli, autenticazione, eventuali limiti d'uso;
• dati del cliente: chi ne è titolare, dove sono ospitati, chi può accedervi;
• export e portabilità: in quale formato i dati possono essere recuperati, in quanto tempo, con quale completezza;
• SLA: livelli di servizio garantiti, tempi di ripristino, gestione degli incidenti;
• backup: chi li esegue, con quale frequenza, per quanto tempo vengono conservati;
• recesso e cessazione: cosa succede ai dati e all'operatività quando il contratto termina;
• continuità del servizio: cosa accade in caso di problemi del provider, acquisizioni, dismissioni del prodotto;
• privacy e GDPR: ubicazione dei dati, eventuali trasferimenti extra-UE, ruolo del provider come responsabile o titolare del trattamento.

Un punto spesso sottovalutato è il lock-in dei dati. Anche quando il cliente è formalmente titolare dei propri dati, le condizioni concrete di recupero possono variare molto: c'è un export completo o solo parziale? È un formato standard o una struttura proprietaria? I dati storici sono inclusi? Le configurazioni e le personalizzazioni sono esportabili? Le risposte a queste domande determinano, nei fatti, quanto è possibile cambiare provider o portare i dati altrove.

Nei panni del cliente

Davanti a un servizio SaaS, la mentalità giusta non è quella di chi compra un prodotto, ma quella di chi affida un pezzo della propria operatività a un fornitore esterno. Il software, di per sé, conta meno del rapporto di servizio: stabilità del provider, qualità del supporto, gestione delle continuità, trattamento dei dati.

Le domande chiave diventano molto concrete:

• posso recuperare i miei dati? In che formato? Con quale livello di dettaglio? In quanto tempo?
• cosa succede se smetto di pagare? Per quanto tempo i dati restano accessibili o recuperabili?
• cosa succede se il fornitore cambia condizioni, viene acquisito, dismette il servizio?
• chi accede ai miei dati, in quali condizioni, da dove?
• se il servizio è centrale per la mia attività, esiste un piano di continuità credibile in caso di interruzione?

Il SaaS non è, di per sé, un modello "peggiore" o "migliore" del software installato. In molti contesti è la soluzione più ragionevole: meno costi infrastrutturali, aggiornamenti automatici, scalabilità immediata. Ma sposta il baricentro della valutazione: dal "cosa possiedo" al "da chi dipendo, e a quali condizioni".

Per questo, in un progetto che include o si appoggia a servizi SaaS, vale la pena valutare con la stessa attenzione due cose: le funzionalità del servizio, e le clausole che regolano cosa accade quando le cose cambiano.

Open source: una premessa necessaria

Il software open source è una delle risorse più importanti dello sviluppo contemporaneo. Quasi tutti i progetti software moderni, proprietari, commerciali, su misura, SaaS, incorporano in misura più o meno ampia componenti open source. Senza, sarebbe semplicemente impossibile costruire prodotti competitivi nei tempi e con i costi attuali.

Allo stesso tempo, "open source" non significa "senza regole". Significa che il codice sorgente è reso disponibile secondo i termini di una licenza specifica, che ne regola uso, modifica e redistribuzione. Alcune licenze sono molto permissive, altre impongono obblighi precisi. Ignorare quei termini non rende il software gratuito o privo di vincoli: rende il suo utilizzo non conforme.

Per leggere correttamente le diverse licenze open source, servono due distinzioni fondamentali.

La prima è tra uso interno e distribuzione. Molti obblighi delle licenze open source si attivano solo nel momento in cui il software (o un suo derivato) viene distribuito a soggetti esterni, anche se alcuni obblighi, come attribuzioni o conservazione dei testi di licenza, possono comunque essere rilevanti nella gestione del progetto. Usare un componente open source dentro un sistema interno aziendale è una situazione molto diversa dal distribuirlo come parte di un prodotto commerciale o di un servizio pubblico.

La seconda è tra distribuzione tradizionale e servizio erogato via rete. Per molto tempo le licenze open source sono state pensate per uno scenario in cui il software veniva consegnato a un utente, che lo installava sulla propria macchina. L'avvento dei servizi web e del SaaS ha cambiato le carte in tavola: alcune licenze sono state aggiornate per coprire anche questi scenari, altre no. È una distinzione che torna utile soprattutto quando si parla di AGPL.

Tenendo a mente queste due distinzioni, le principali famiglie di licenze open source diventano molto più leggibili.

Licenze permissive: MIT, BSD, Apache 2.0

Parte tecnico-legale

Le licenze permissive sono quelle che impongono il minor numero di obblighi. MIT e BSD (in diverse varianti) sono tra le più semplici in circolazione: consentono di usare, modificare, integrare e ridistribuire il software, anche a fini commerciali, anche all'interno di prodotti proprietari. L'obbligo principale è quello di mantenere gli avvisi di copyright e la licenza originaria nei file derivati o nella documentazione di accompagnamento.

Apache 2.0 segue la stessa logica permissiva, ma è scritta in modo più articolato. Aggiunge alcuni elementi rilevanti, in particolare per contesti enterprise:

• una concessione esplicita relativa ai brevetti detenuti dai contributori, che riduce alcuni rischi legali;
• una clausola che disattiva tale concessione se chi usa il software intenta cause brevettuali contro i contributori;
• requisiti più espliciti sulla segnalazione delle modifiche apportate al codice originario.

Per queste ragioni Apache 2.0 è spesso preferita nei progetti aziendali e nei contesti in cui i temi brevettuali hanno un peso. Resta comunque, dal punto di vista pratico, una licenza permissiva.

Alcune varianti storiche di BSD avevano clausole più problematiche; nelle versioni moderne più diffuse, come BSD 2-Clause e 3-Clause, questi aspetti sono generalmente superati.

Nei panni del cliente

Per un cliente che commissiona un progetto, sapere che il fornitore utilizza componenti MIT, BSD o Apache 2.0 è di solito una notizia rassicurante. Questi componenti possono essere integrati in software proprietari, in prodotti commerciali, in servizi a pagamento, senza che ciò comporti l'obbligo di rendere pubblico il codice del progetto complessivo.

Questo, però, non significa "nessun obbligo". I requisiti di attribuzione e conservazione delle licenze sono reali: significa che, nei file derivati, nella documentazione o in apposite sezioni del software, devono essere mantenuti i riferimenti agli autori originari e ai testi delle licenze. Non è un peso significativo, ma è un'attività che va fatta correttamente.

In pratica, un cliente che riceve un software costruito su componenti permissive può aspettarsi:

• di poterlo usare, modificare e far modificare con una notevole libertà;
• di poterlo integrare in altri sistemi senza obblighi di "apertura" del proprio codice;
• di doversi assicurare che gli avvisi di licenza siano correttamente conservati nei materiali distribuiti o consegnati;
• di non poter rivendicare la paternità esclusiva delle componenti di terzi inglobate nel progetto.

Le licenze permissive sono uno dei motivi per cui lo sviluppo software moderno è così rapido. Ma descriverle come "puoi fare tutto" è un errore: gli obblighi sono pochi, ma esistono, e il rispetto di quegli obblighi è parte della qualità del progetto.

Copyleft forte: GPL

Parte tecnico-legale

La famiglia GPL (General Public License) appartiene a una categoria diversa: quella delle licenze copyleft. L'idea di fondo è chiara: chi riceve software GPL ha diritto di usarlo, studiarlo, modificarlo e ridistribuirlo, ma, se decide di distribuire una versione modificata o un'opera derivata, deve farlo alle stesse condizioni, mantenendo cioè la disponibilità del codice sorgente per i destinatari.

È un meccanismo pensato per far sì che il software libero resti libero anche quando viene esteso o modificato. Le versioni più diffuse sono GPLv2 e GPLv3, con alcune differenze tecniche (in particolare su brevetti, compatibilità con altre licenze e gestione di dispositivi che impediscono modifiche).

I punti che vanno tenuti presenti sono diversi:

• uso interno e distribuzione sono trattati diversamente: usare software GPL all'interno di un'azienda, senza distribuirlo all'esterno, normalmente non attiva gli obblighi di rilascio del sorgente;
• opera derivata è un concetto chiave: incorporare codice GPL in un altro software in modo "stretto" può far ricadere il risultato complessivo, o parti rilevanti di esso, negli obblighi previsti dalla GPL al momento della distribuzione;
• integrazione con codice proprietario: combinare GPL e codice proprietario richiede attenzione, perché in molti scenari le due cose non sono compatibili in vista di una distribuzione commerciale chiusa;
• la valutazione dipende sempre dal modo concreto in cui i componenti sono integrati: linking, separazione di processi, comunicazione via interfacce, distinzioni non sempre facili da valutare senza un'analisi specifica.

Nei panni del cliente

Per un cliente, la presenza di componenti GPL in un progetto non è automaticamente un problema. Dipende molto da cosa si intende fare con il software.

Se il software è destinato a un uso interno, un gestionale aziendale, una piattaforma usata solo dai dipendenti, uno strumento di backoffice, la presenza di componenti GPL, in molti casi, non comporta obblighi particolari di apertura del codice, perché non c'è distribuzione esterna.

La situazione cambia quando il software viene distribuito. Se il progetto deve essere consegnato a clienti finali, venduto come prodotto, distribuito a partner esterni, o se incorpora componenti GPL in modo strutturale, allora gli obblighi GPL possono attivarsi e richiedere che il sorgente sia messo a disposizione dei destinatari. È un'eventualità che va valutata prima di prendere decisioni architetturali, non dopo.

Le domande utili da porre, in questo caso, sono concrete:

• il progetto include componenti GPL? Quali?
• il software è destinato a uso interno o sarà distribuito a terzi?
• l'integrazione con il codice custom è tale da far considerare il risultato un'opera derivata?
• esistono alternative non-GPL che svolgono la stessa funzione, se la GPL crea attrito con il modello di business previsto?

Va detto chiaramente: la GPL non è una licenza "ostile". È una licenza con una filosofia precisa, che funziona molto bene in molti contesti. Ma è una licenza che richiede consapevolezza nelle scelte tecniche, e che non si presta a essere usata distrattamente all'interno di prodotti commerciali chiusi.

AGPL: il copyleft pensato per la rete

Parte tecnico-legale

La AGPL (Affero General Public License) è una variante della GPL pensata per rispondere a un'evoluzione del software: la diffusione dei servizi online. La GPL classica si attiva con la distribuzione: se il software resta installato sui server del fornitore e viene erogato come servizio, gli obblighi GPL non scattano. È il cosiddetto "buco SaaS".

L'AGPL nasce proprio per coprire questo scenario. Stabilisce che, anche quando il software modificato viene reso accessibile attraverso una rete (tipicamente come servizio web), gli utenti che interagiscono con esso devono poter ottenere il codice sorgente della versione utilizzata. È un'estensione importante, che cambia il modo in cui la licenza si applica nei contesti cloud.

Per questo, l'AGPL è particolarmente delicata in scenari come:

• piattaforme web e portali aperti al pubblico;
• gestionali cloud e servizi SaaS;
• API esposte a terzi;
• qualunque sistema in cui un software modificato sia raggiungibile via rete da soggetti esterni all'organizzazione.

La presenza di un componente AGPL in un'architettura di questo tipo richiede una valutazione molto attenta delle implicazioni, perché può generare obblighi di disponibilità del codice sorgente anche in scenari nei quali, con altre licenze, il solo utilizzo via rete non avrebbe avuto lo stesso effetto.

Nei panni del cliente

Per un cliente, la regola pratica è semplice: se il progetto è una piattaforma online, un'applicazione cloud, un servizio web, o include un'interfaccia rivolta a utenti esterni, i componenti AGPL non possono essere inseriti distrattamente.

Non significa che siano "vietati". Esistono prodotti e progetti pienamente coerenti con AGPL, e in alcuni contesti la scelta di adottarla è perfettamente ragionevole. Ma l'AGPL è una licenza che ha conseguenze sull'architettura complessiva del servizio, e quelle conseguenze vanno comprese e accettate consapevolmente.

Le domande utili in fase di progetto sono poche e dirette:

• il progetto è un servizio accessibile via rete da utenti esterni?
• ci sono componenti AGPL nello stack tecnico?
• se sì, sono usati come elementi separati o sono integrati nel software custom?
• siamo disposti, in caso di obblighi attivati, a rendere disponibile il codice sorgente delle parti coinvolte?

Una scelta architetturale fatta senza considerare queste domande può portare, mesi o anni dopo, a doverle affrontare in condizioni molto meno comode.

LGPL: un copyleft più contenuto

Parte tecnico-legale

La LGPL (Lesser General Public License) è una forma di copyleft più contenuta, pensata principalmente per le librerie. La logica è quella di consentire l'uso di codice libero anche all'interno di software proprietari, ma a condizioni precise.

In sintesi, la LGPL prevede che:

• la libreria stessa, se modificata, resti soggetta agli obblighi di apertura del codice in caso di distribuzione;
• il software proprietario che si limita a utilizzare la libreria (senza modificarla) può restare chiuso;
• in molti scenari di distribuzione, l'utente finale deve poter sostituire la libreria con una versione modificata, secondo quanto previsto dalla licenza: è il cosiddetto principio di sostituibilità, che ha implicazioni concrete sulle modalità tecniche di integrazione (linking dinamico, separazione, fornitura di file oggetto o equivalenti).

Le versioni della LGPL (in particolare la 2.1 e la 3) si differenziano per alcuni dettagli, ma la logica complessiva resta quella descritta.

È importante non assimilarla alle licenze permissive: la LGPL non è permissiva. Rispetto alla GPL è più compatibile con scenari proprietari, ma impone comunque obblighi che vanno gestiti correttamente, soprattutto se la libreria viene modificata o se le modalità di integrazione tecnica non garantiscono la sostituibilità.

Nei panni del cliente

Per un cliente, la presenza di componenti LGPL in un progetto è in molti casi compatibile con un modello commerciale chiuso. È, in effetti, uno dei motivi per cui la LGPL è scelta da molti progetti di librerie destinate a essere usate in ambito enterprise.

Le condizioni da rispettare, però, esistono e non sono trascurabili:

• se la libreria viene modificata, le modifiche normalmente devono essere rese disponibili in caso di distribuzione;
• il software che la utilizza deve essere costruito in modo da consentire la sostituzione della libreria con una versione alternativa, almeno nei limiti previsti dalla licenza;
• gli obblighi di attribuzione e conservazione del testo della licenza si applicano come per le altre licenze copyleft.

In pratica, la LGPL non è un problema in sé, ma richiede che le scelte tecniche di integrazione siano fatte con consapevolezza. Trattarla come una licenza permissiva qualunque è un errore, che può portare a situazioni di non conformità anche in progetti tecnicamente ben fatti.

Una nota trasversale sull'open source

Le licenze open source non sono nemiche del software commerciale: ne sono una parte essenziale. Praticamente tutti i sistemi moderni, anche quelli pensati per essere chiusi e proprietari, si appoggiano a componenti open source di vario tipo.

La differenza tra un progetto fatto bene e uno fatto male non sta nell'usare o non usare open source. Sta nel sapere quale open source si sta usando, sotto quale licenza, con quali obblighi e con quali conseguenze pratiche. Una buona prassi, in fase di consegna o di rendicontazione, è quella di mantenere un elenco aggiornato dei componenti open source utilizzati, con le rispettive licenze: una sorta di "distinta base" del software, utile sia per il fornitore sia per il cliente.

È un'attività poco appariscente, ma ha un valore reale: trasforma un'area potenzialmente opaca in un dato gestibile.

Creative Commons: per i contenuti, non per il codice

Parte tecnico-legale

Le licenze Creative Commons (CC) sono uno strumento importante, ma vanno collocate correttamente: sono pensate principalmente per contenuti, non per software. Si applicano in modo naturale a testi, immagini, fotografie, video, materiali grafici, documentazione, dataset, contenuti educativi, lavori artistici. Per il codice esistono licenze specifiche, e le linee guida ufficiali di Creative Commons stessa sconsigliano di usare le CC per software.

Il sistema Creative Commons funziona per combinazione di clausole, ognuna delle quali aggiunge una condizione. Le principali sono:

• BY (Attribuzione): l'autore originale deve essere citato;
• SA (ShareAlike, "stesse condizioni"): le opere derivate devono essere distribuite con la stessa licenza;
• NC (Non Commercial): l'uso commerciale è vietato;
• ND (No Derivatives): non sono ammesse modifiche.

Da queste si formano le varianti più diffuse: CC BY, CC BY-SA, CC BY-NC, CC BY-NC-SA, CC BY-ND, e così via. Esiste anche CC0, pensata per rinunciare, per quanto consentito, ai diritti sull'opera e avvicinarla al pubblico dominio.

Le differenze tra una variante e l'altra sono significative. Una CC BY consente usi molto ampi, anche commerciali. Una CC BY-NC esclude l'uso commerciale. Una CC BY-ND impedisce di pubblicare modifiche dell'opera originale. La sigla precisa, in pratica, conta molto.

Nei panni del cliente

Per un cliente, il tema delle Creative Commons riguarda soprattutto i contenuti che entrano nel progetto: testi, fotografie, illustrazioni, icone, video, dataset, documentazione di accompagnamento, materiali di marketing.

Anche un sito web o una piattaforma evoluta non è fatta solo di codice. È fatta anche di immagini di copertina, fotografie di prodotto, illustrazioni, set di icone, video, infografiche, contenuti testuali e, più in generale, asset creativi. Ognuno di questi elementi ha la sua licenza, e il fatto che sia stato "trovato online" non lo rende automaticamente utilizzabile.

Le domande utili da porre, in fase di consegna, sono concrete:

• da dove provengono le immagini, le icone e i contenuti grafici utilizzati?
• sotto quale licenza sono distribuiti?
• la licenza copre l'uso commerciale, o solo personale e didattico?
• sono ammesse modifiche, o l'opera deve restare invariata?
• i contenuti possono essere riutilizzati in altre sedi, su materiali stampati, in campagne di marketing?
• nei casi previsti, le attribuzioni richieste sono effettivamente presenti nel sito o nei materiali consegnati?

Per il codice software, invece, le Creative Commons non sono lo strumento adatto. Se un componente software che entra in un progetto è etichettato come CC, vale la pena chiedere chiarimenti: nella maggior parte dei casi, per il codice, esiste una licenza più appropriata.

Licenze commerciali di terze parti

Parte tecnico-legale

Quasi tutti i progetti software realmente usati incorporano elementi commerciali di terze parti: plugin premium, template, librerie UI, font, immagini stock, componenti grafici, servizi cloud, API esterne a pagamento. Sono pezzi del sistema senza i quali, in molti casi, sarebbe impossibile rispettare tempi e budget di progetto.

Ogni componente di questo tipo arriva con una licenza propria, che governa diversi aspetti:

• perimetro d'uso: la licenza è valida per un sito, un dominio, un'azienda, un server, un numero di utenti, un singolo progetto?
• trasferibilità: la licenza può essere ceduta a un altro soggetto, o resta vincolata all'intestatario?
• aggiornamenti e supporto: sono inclusi a tempo indeterminato, oppure dipendono da un abbonamento attivo?
• rivendita e distribuzione: il componente può essere ridistribuito, integrato in prodotti destinati a clienti terzi, o solo usato direttamente?
• rinnovi: cosa succede alla scadenza dell'abbonamento? Il componente continua a funzionare? Smette di ricevere aggiornamenti? Si disattiva?

Le risposte variano molto da prodotto a prodotto. Una licenza per un plugin premium può essere "lifetime" oppure annuale; una licenza di un servizio API può essere a consumo oppure a piano fisso; una libreria UI commerciale può essere "per sviluppatore", "per progetto" o "per azienda". Sono distinzioni che, in fase di acquisto, determinano costi e vincoli operativi a lungo termine.

Nei panni del cliente

Per un cliente, la domanda più importante in tema di componenti commerciali è anche la più semplice, e quella che spesso viene posta tardi: a nome di chi sono intestate le licenze?

Esistono, in pratica, due scenari principali, ed entrambi sono legittimi:

• le licenze sono intestate al cliente, che paga direttamente il produttore o il servizio terzo (a volte tramite il proprio account, a volte tramite il fornitore di sviluppo);
• le licenze sono intestate al fornitore di sviluppo, che le utilizza per costruire il progetto e ne gestisce il rinnovo nel quadro del rapporto con il cliente.

Entrambe le impostazioni hanno senso, in contesti diversi. Ma ognuna ha conseguenze precise sul lungo periodo. Se le licenze sono intestate al fornitore, in caso di interruzione del rapporto possono nascere domande operative concrete: il cliente ha il diritto di continuare a usare quei componenti? Il fornitore può "trasferirgliele"? Ed eventualmente, a quali condizioni? Se invece sono intestate al cliente, è il cliente stesso a doversi occupare di rinnovi, scadenze e gestione degli account.

Le domande utili, in entrambi i casi, sono operative:

• esiste un elenco aggiornato dei componenti commerciali utilizzati nel progetto?
• per ognuno, è chiaro chi è il titolare della licenza, qual è la scadenza, qual è il costo di rinnovo?
• cosa succede se uno di questi componenti smette di essere supportato o aggiornato dal produttore?
• in caso di passaggio a un altro fornitore, le licenze possono essere trasferite, o vanno acquistate ex novo?
• quali parti del sistema dipendono in modo critico da componenti commerciali esterni, e quali alternative esisterebbero in caso di necessità?

Anche qui, una distinta base aggiornata dei componenti utilizzati, questa volta per la parte commerciale di terze parti, è uno strumento di governance semplice e prezioso.

Framework, starter kit e componenti proprietari del fornitore

Parte tecnico-legale

Molti fornitori di software lavorano sopra una propria base tecnica: un framework interno, uno starter kit riutilizzabile, un CMS proprietario, una libreria di componenti, un insieme di moduli sviluppati nel tempo per accelerare i progetti. È una pratica comune, e ha una logica precisa: anziché ricominciare ogni volta da zero, il fornitore capitalizza la propria esperienza in strumenti riusabili, che riducono tempi, costi e rischi di nuovi progetti.

Da un punto di vista contrattuale, in questo scenario un progetto consegnato al cliente convive con due livelli distinti:

• il codice specifico del cliente: la parte sviluppata su misura per quel progetto, sulla base dei requisiti concordati;
• la base tecnica del fornitore: framework, librerie interne, componenti generici, infrastrutture di sviluppo che il fornitore ha costruito (e continua a far evolvere) indipendentemente dal singolo progetto.

I due livelli possono essere governati da regimi diversi. Il codice specifico può essere ceduto al cliente, o concesso in licenza con un perimetro ampio, o consegnato come parte di un servizio più ampio. La base tecnica, in molti casi, resta proprietà del fornitore, che ne concede al cliente un diritto d'uso funzionale al progetto: il software finale funziona, può essere mantenuto, può evolvere, ma il fornitore mantiene la proprietà degli strumenti generici sottostanti.

Questo schema, di per sé, non è opaco né penalizzante per il cliente. Lo diventa solo se non viene dichiarato.

Nei panni del cliente

Per un cliente, il fatto che il fornitore lavori sopra una propria base tecnica non è automaticamente un problema. Anzi, in molti casi è un vantaggio: significa che il fornitore sta applicando scelte già consolidate, testate e manutenute, invece di ripartire ogni volta da zero. Tempi più rapidi, meno bug evitabili, qualità più stabile.

Il punto, però, è che questo deve essere dichiarato in modo esplicito.

È importante chiarire, prima di firmare, come è composto il sistema che verrà consegnato: quali parti sono codice scritto specificamente per quel cliente, quali parti provengono dal framework o dai componenti proprietari del fornitore, quali parti sono open source, quali sono di terze parti commerciali. E quale regime si applica a ciascuna di queste parti: cosa è ceduto, cosa è concesso in licenza, cosa resta proprietà del fornitore.

Le domande utili sono, anche in questo caso, molto pratiche:

• il progetto poggia su un framework o un CMS interno del fornitore? Se sì, quale è il suo ruolo nel sistema?
• in che misura il funzionamento del software dipende da quel framework?
• quali parti del progetto sono codice specifico, e quali sono componenti riutilizzabili del fornitore?
• in caso di interruzione del rapporto, il cliente può continuare a usare il software? Con quali limiti?
• il fornitore mantiene il diritto di riusare le componenti generiche per altri clienti? (Di norma sì, ed è ragionevole, purché sia dichiarato.)
• esiste documentazione sufficiente per intervenire sul codice specifico, anche da parte di un altro fornitore tecnicamente competente?

Affrontare questi temi all'inizio del progetto non irrigidisce il rapporto: lo rende più stabile. Un fornitore che spiega con chiarezza la propria base tecnica e i regimi che la governano sta dando al cliente uno strumento di valutazione, non meno trasparenza.

La trasparenza non consiste nel consegnare tutto senza distinzione. Consiste nel dichiarare con precisione quali parti del sistema sono trasferibili, modificabili, riutilizzabili o vincolate.

È un principio che vale per il fornitore, che ha l'onere di rendere esplicita la struttura del progetto, ma anche per il cliente, che ha l'opportunità di chiedere e di documentare quanto gli viene dichiarato. La chiarezza, qui, non è un atto di formalismo: è una condizione di lavoro.

La zona grigia dei progetti reali

Le sezioni precedenti hanno trattato le licenze come categorie distinte, perché distinte effettivamente sono. Ma nei progetti veri queste categorie non si presentano mai in isolamento: si incontrano, si stratificano, si combinano. Un progetto software reale è quasi sempre un sistema composto, in cui licenze e regimi di proprietà diversi convivono nello stesso sistema.

In un progetto tipico, un gestionale, una piattaforma web, un'applicazione su misura, è ragionevole aspettarsi di trovare livelli come questi:

• codice custom, sviluppato specificamente per il progetto;
• framework, starter kit o componenti proprietari del fornitore, riutilizzati dal suo bagaglio tecnico;
• librerie open source, ognuna con la propria licenza;
• plugin e moduli commerciali di terze parti;
• template grafici e set di componenti UI;
• font, con le proprie licenze d'uso;
• immagini, icone e contenuti, sotto regimi che possono variare da Creative Commons a licenze stock commerciali;
• API esterne e servizi cloud, regolati dai propri termini di servizio;
• database e relativi engine, ciascuno con la propria licenza;
• configurazioni server, infrastrutture e ambienti di esecuzione;
• script di deploy e strumenti di automazione;
• documentazione tecnica e materiali di accompagnamento;
• dati del cliente, con un proprio regime di titolarità e responsabilità.

Ognuno di questi livelli può avere una licenza, una proprietà e un regime contrattuale diversi. Il sistema funziona come un insieme, ma non è regolato da un solo livello contrattuale o da una sola licenza: è governato da una composizione di atti, alcuni già compatibili tra loro, altri da verificare e armonizzare con attenzione.

Per questo, in molti casi, la domanda "di chi è il software?" è una domanda mal posta. Non perché sia illegittima, ma perché presuppone una risposta unica laddove la realtà è stratificata. Una risposta più utile, e più operativa, si ottiene cambiando la formulazione:

Quali parti del sistema posso usare, modificare, trasferire, rivendere, migrare o affidare a un altro fornitore, e a quali condizioni?

Posta così, la domanda costringe a guardare il progetto per quello che effettivamente è: un'architettura di componenti, ognuno con i propri vincoli e le proprie libertà. È una formulazione che non semplifica la realtà, ma la rende leggibile. E, in pratica, è il punto di partenza di qualunque discussione seria sulla continuità, sulla manutenzione e sull'evoluzione del progetto nel tempo.

Cosa dovrebbe chiedere il cliente prima di iniziare

Le sezioni precedenti delineano il contesto. Ora si tratta di trasformarlo in qualcosa di operativo: un piccolo set di domande che un cliente, anche non tecnico, può portare in qualunque tavolo di lavoro all'inizio di un progetto software. Non sono domande "diffidenti": sono domande di chiarezza, e un fornitore strutturato dovrebbe saperle affrontare con naturalezza.

Per leggibilità, le abbiamo raggruppate per area tematica.

Codice e diritti

• Il codice sorgente sarà consegnato al termine del progetto? Tutto, in parte, oppure solo la parte specifica del cliente?
• Con quale licenza potrò usarlo, e per quali finalità?
• Quali parti resteranno proprietà del fornitore (ad esempio framework, starter kit, componenti riutilizzabili)?
• Posso far modificare il software da un altro fornitore in futuro?
• Posso installarlo su un'altra infrastruttura, su un altro server, su un altro cloud?
• Posso usarlo per più sedi, società del gruppo o per clienti finali?
• Posso rivendere o distribuire il software come parte di un mio prodotto?

Componenti di terze parti

• Quali componenti open source vengono utilizzati nel progetto?
• Ne esiste una distinta base aggiornata (l'elenco completo dei componenti, spesso chiamato anche Software Bill of Materials o SBOM)?
• Sono presenti componenti GPL, AGPL o LGPL, e in tal caso come sono integrati con il resto del sistema?
• Sono utilizzati plugin, template, librerie UI, font, API esterne o altri componenti commerciali soggetti a rinnovo?
• A nome di chi sono intestate le licenze di questi componenti? Cosa cambia, in caso di interruzione del rapporto?

Dati e operatività

• I dati gestiti dal sistema sono esportabili?
• In quale formato, con quale livello di completezza, in quanto tempo?
• I dati storici, le configurazioni e le personalizzazioni sono inclusi nell'export?
• Esistono backup? Chi li gestisce, con quale frequenza, per quanto tempo sono conservati?
• Dove sono fisicamente ospitati i dati e quali implicazioni ci sono in tema di privacy e GDPR?

Continuità e fine rapporto

• Cosa succede al termine del contratto? Per quanto tempo il software continua a funzionare? Per quanto tempo i dati restano accessibili?
• È prevista, contrattualmente, una forma di assistenza alla migrazione verso un altro fornitore o un'altra infrastruttura?
• Sono documentati in modo sufficiente installazione, dipendenze, backup, ripristino e deploy, in modo che un altro soggetto tecnicamente competente possa intervenire?
• In caso di componenti critici proprietari del fornitore, esistono clausole di continuità in caso di cessazione dell'attività o di mancato supporto?

L'obiettivo, qui, non è ottenere garanzie assolute, non esistono, ma costruire una mappa chiara di ciò che il progetto contiene, di ciò che il cliente potrà farne, e di ciò che resterà fuori dal proprio perimetro. Una mappa così, condivisa con il fornitore prima di partire, riduce significativamente il rischio di sorprese future.

Cosa dovrebbe chiarire il fornitore

Le stesse domande, viste dall'altro lato del tavolo, generano una checklist speculare per il fornitore. Anzi: in un rapporto sano, è il fornitore stesso a portare in conversazione molti di questi temi, prima ancora che il cliente li sollevi. Non per generosità, ma per metodo: una proposta tecnica è solida quando è anche una proposta contrattualmente chiara.

In sintesi, un fornitore strutturato dovrebbe essere in grado di rispondere, con precisione, a domande come queste.

Cosa vende e a che condizioni

• Sta vendendo un prodotto standard, una sua configurazione, uno sviluppo su misura o una combinazione di queste cose?
• Quali diritti vengono concessi al cliente, e in quale forma (cessione, licenza d'uso, accesso al codice)?
• Esistono limiti di utilizzo (sedi, utenti, ambito territoriale, finalità)?
• Il rapporto prevede un canone, un acquisto una tantum, o un modello misto?

Cosa viene ceduto e cosa resta al fornitore

• Quali parti del progetto sono codice specifico del cliente e quali appartengono al bagaglio tecnico del fornitore (framework, starter kit, componenti riutilizzabili)?
• Quali parti sono open source, sotto quali licenze, e con quali eventuali obblighi a carico del cliente?
• Quali sono i componenti commerciali di terze parti, a nome di chi sono intestate le relative licenze, quali sono i costi e le scadenze di rinnovo?
• Il fornitore mantiene il diritto di riusare componenti generici per altri clienti? In quale forma?

Cosa viene consegnato (e cosa no)

• Cosa farà parte della consegna al termine del progetto: codice sorgente, eseguibili, configurazioni, ambienti di esecuzione, documentazione, accessi?
• Cosa non farà parte della consegna, e perché?
• Quale documentazione tecnica accompagna il progetto: installazione, dipendenze, deploy, backup, ripristino, eventuali procedure operative?

Continuità, manutenzione e fine rapporto

• Quali attività rientrano nella manutenzione ordinaria e quali sono extra?
• In caso di interruzione del rapporto, cosa resta funzionante e cosa richiede un intervento di subentro?
• Quali parti del sistema sono critiche per la continuità operativa, e come è gestita questa criticità?
• Esistono clausole specifiche per la gestione dei dati alla fine del contratto (export, conservazione, cancellazione)?

Non si tratta di trasformare ogni offerta in un trattato. Si tratta di assicurarsi che, su queste aree, esista una posizione chiara e dichiarabile. Un'offerta tecnica che evita sistematicamente questi temi non è necessariamente in malafede, può semplicemente essere incompleta. Ma il rischio, in entrambi i casi, è lo stesso: temi che non vengono affrontati all'inizio del progetto tendono a riemergere, in forma più complicata, quando il rapporto si trova sotto pressione.

Per questo, in fondo, la chiarezza sulle licenze non è un atto di rigidità contrattuale. È un atto di manutenzione preventiva del rapporto: serve a evitare conflitti quando il progetto cresce, cambia fornitore, cambia infrastruttura o diventa strategico.

Domande frequenti

Una raccolta di domande pratiche che ricorrono nei progetti reali. Le risposte sono sintetiche, di principio, e vanno sempre lette alla luce del contratto specifico e con il supporto di un professionista.

Ho pagato il software: è mio?

Non automaticamente. Il pagamento di uno sviluppo dà di norma un diritto d'uso, non la proprietà del codice. Perché i diritti patrimoniali passino al cliente serve una cessione esplicita nel contratto. E anche allora, la cessione riguarda di solito solo il codice custom, non librerie, framework e componenti di terze parti che restano governati dalle proprie licenze.

Posso rivenderlo o distribuirlo come prodotto?

Solo se il contratto lo prevede in modo esplicito. Anche con una cessione ampia dei diritti sul codice custom, la rivendita o la distribuzione possono essere limitate dalle componenti incorporate: una libreria copyleft, un plugin commerciale "single project", un framework proprietario del fornitore possono rendere impossibile, o richiedere accordi aggiuntivi, l'uso del software come prodotto da rivendere.

Posso dare il codice a un altro programmatore o cambiare fornitore?

Dipende da due livelli. Il primo è contrattuale: il contratto deve consentire la consegna del codice e l'intervento di terzi. Il secondo è operativo: il subentro è realmente possibile solo se esistono documentazione, dipendenze dichiarate, ambienti di sviluppo replicabili e accessi all'infrastruttura. Sulla carta i diritti possono essere ampi, ma senza queste condizioni il lock-in operativo resta.

Se ricevo il sorgente, posso farci quello che voglio?

No. Avere il codice è una condizione tecnica di intervento, non un titolo di libertà d'uso. Un cliente può ricevere il sorgente per continuità operativa (manutenzione, emergenze, indipendenza dal fornitore) senza acquisire il diritto di rivenderlo, distribuirlo o usarlo come base per un prodotto. Accesso al codice e diritti di sfruttamento sono dimensioni separate.

Posso usare lo stesso software in un'altra società del gruppo?

Solo se la licenza lo prevede. Le licenze definiscono in modo preciso il perimetro d'uso: una sede, un'azienda, un gruppo, un territorio. Un'estensione a società collegate, controllate o consociate va concordata in modo esplicito; non si può presumere come effetto naturale del rapporto.

Se cambio fornitore, cosa succede?

Dipende da come è stato impostato il progetto. Nei casi sani: il codice custom è consegnato, le componenti di terze parti sono intestate al cliente o trasferibili, la documentazione consente a un soggetto tecnicamente competente di subentrare, i dati sono esportabili in un formato utilizzabile. Quando uno di questi pezzi manca, il cambio di fornitore non è impossibile, ma diventa un progetto a sé, con costi e tempi non banali. È esattamente il motivo per cui questi temi vanno chiariti prima di iniziare.

Con un budget contenuto, compro anche i diritti di rivendita?

Quasi mai, e non è una questione di budget. La cessione dei diritti commerciali su un sistema, o la concessione di una licenza con diritto di rivendita, è un atto contrattuale specifico che ha un valore economico autonomo rispetto allo sviluppo. In assenza di una clausola dedicata, il pagamento dello sviluppo non include automaticamente la facoltà di rivendere il software a terzi, indipendentemente dall'importo.

Open source significa "gratis e senza vincoli"?

No. Open source significa che il codice è disponibile secondo i termini di una licenza specifica, che impone obblighi diversi a seconda della famiglia: dalle attribuzioni delle licenze permissive (MIT, BSD, Apache 2.0), agli obblighi di rilascio del sorgente delle copyleft (GPL), fino agli obblighi di disponibilità via rete dell'AGPL. Trattare l'open source come "gratis" porta, prima o poi, a situazioni di non conformità.

E Iteranea come si comporta nei propri progetti software?

Iteranea chiarisce questi aspetti prima dell'avvio del progetto. In generale, distinguiamo tra uso operativo del software, consegna del codice per continuità e manutenzione, cessione dei diritti patrimoniali, possibilità di rivendita o uso white-label. Sono livelli diversi, con valori economici e contrattuali diversi.

La nostra impostazione è semplice: tutto può essere previsto, ma tutto deve essere dichiarato e valorizzato nel contratto. Se un cliente vuole usare il software per la propria attività, il progetto viene regolato in quel perimetro. Se invece vuole rivenderlo, distribuirlo a terzi o trasformarlo in un prodotto autonomo, serve un accordo specifico.

Allo stesso tempo, Iteranea tutela il proprio patrimonio tecnico: framework, librerie interne, starter kit, moduli generici e know-how non vengono automaticamente ceduti solo perché fanno parte di un progetto. Possono essere concessi in uso per far funzionare il sistema, ma il loro riuso fuori dal perimetro concordato va regolato.

Questo approccio non serve a creare dipendenza, ma a evitare equivoci. Il cliente deve avere continuità operativa e chiarezza su ciò che può fare; il fornitore deve poter proteggere il lavoro e le basi tecniche costruite nel tempo.

La licenza come parte dell'architettura del software

Si tende a immaginare la licenza come un allegato. Un documento che si firma a margine del contratto, che si archivia in qualche cartella e che, nei casi migliori, non si rilegge più. Le pagine precedenti dovrebbero aver suggerito che le cose stanno diversamente.

La licenza è, in molti casi, anche una scelta architetturale. Non architetturale nel senso tecnico stretto, non riguarda direttamente come è scritto il codice, ma architetturale nel senso più ampio: incide sul modo in cui il software potrà evolvere nel tempo, su chi potrà manutenerlo, su quanto potrà essere trasferito o riutilizzato, su come potrà essere integrato con altri sistemi, su cosa accadrà nei momenti di passaggio. È una scelta che, come tutte le scelte architetturali, agisce sul lungo periodo, e i suoi effetti diventano visibili soprattutto quando il progetto cambia: cresce, si sposta su un'altra infrastruttura, viene affidato ad altri, diventa parte di un'operazione strategica.

Da questo punto di vista, un software può essere tecnicamente ben fatto e contrattualmente fragile. Sono due piani distinti, ma non separati. Un sistema può funzionare benissimo nelle condizioni in cui nasce e diventare ingestibile non appena quelle condizioni cambiano: un fornitore non più disponibile, una migrazione necessaria, un'evoluzione del business che richiede di mettere mano al codice o ai dati. In quei momenti, ciò che fa la differenza non è solo la qualità della scrittura del codice. È la chiarezza dei diritti, la presenza di documentazione utilizzabile, la possibilità reale, non solo formale, di agire sul sistema.

Per questa ragione, la chiarezza sulle licenze non è un limite imposto al progetto: è un perimetro entro cui il progetto può crescere. Sapere cosa si possiede, cosa si usa in licenza, cosa è di terze parti, cosa resta del fornitore, non chiude opzioni, le definisce. Un progetto privo di questa definizione non è "più libero". È solo meno governabile.

Il punto, in fondo, è semplice: nei progetti software maturi, tecnica, contratto e operatività devono dialogare. La scelta tecnologica influenza i vincoli contrattuali; la struttura contrattuale apre o chiude opzioni operative; la pratica operativa dichiara cosa è davvero sostenibile e cosa no. Quando questi tre piani vengono trattati separatamente, come se il contratto fosse "roba da legali" e la tecnologia "roba da sviluppatori", il progetto resta esposto. Quando dialogano, il progetto diventa robusto.

La licenza è una parte invisibile dell'architettura del software.

Invisibile perché non si vede leggendo il codice, e nemmeno usando il prodotto. Ma è lì, e definisce silenziosamente cosa quel software potrà diventare. Riconoscerlo, e affrontarlo con metodo fin dall'inizio, è una delle differenze più sottili, e più concrete, tra un progetto fatto e un progetto fatto bene.

Per approfondire

Per chi vuole andare oltre questa panoramica, alcuni riferimenti istituzionali sono particolarmente utili.

• Open Source Initiative, la definizione ufficiale di "open source" e l'elenco aggiornato delle licenze riconosciute.
• GNU Project, i testi ufficiali di GPL, AGPL, LGPL, accompagnati da FAQ molto chiare sui casi d'uso più frequenti.
• Apache Software Foundation, il testo della licenza Apache 2.0 e le note di compatibilità con altre licenze.
• Creative Commons, la descrizione delle varianti CC e uno strumento guidato per scegliere la licenza più adatta a un contenuto.
• SPDX License List, l'elenco standardizzato delle licenze software, con identificatori univoci utilizzati per costruire una distinta base (SBOM) leggibile da strumenti automatici.