Cos'è una licenza software e cosa concede davvero?

Una licenza software è il contratto con cui il titolare dei diritti d'autore concede a qualcun altro il permesso di usare, copiare, modificare o distribuire il proprio codice, a condizioni scritte. Il punto che quasi nessuna fonte esplicita è che non si acquista il software come opera: si acquistano diritti su una copia, e il loro limite è la sostanza dell'accordo. Vale identico dentro e fuori dall'open source: una licenza open source concede molti permessi in cambio di poche condizioni, una proprietaria ne concede pochi in cambio di un pagamento, ma la forma giuridica è la stessa e nessuna delle due trasferisce la titolarità dei diritti d'autore. La licenza scelta da chi rilascia decide cosa potrà fare chi riceve: rivendere, ospitare come servizio, incorporare in un prodotto chiuso o soltanto leggere il sorgente. È una decisione economica travestita da formalità legale.

Sulla singola copia la regola europea è però più sfumata di come la si racconta: per la Corte di giustizia (causa C-128/11, UsedSoft) concedere un diritto d'uso perpetuo dietro un pagamento una tantum pari al valore della copia è una vendita, che esaurisce il diritto di distribuzione, e chiamarla licenza nel contratto non cambia la qualificazione. Abbonamenti e licenze a termine restano fuori da questa regola.

Perché esistono famiglie diverse

Le famiglie non sono un catalogo giuridico: sono gli incentivi di chi rilascia.

Il caso delle licenze source-available

Dal 2018 in poi diversi progetti infrastrutturali molto diffusi sono passati alle licenze source-available: MongoDB verso SSPL, Elasticsearch verso SSPL e Elastic License, Terraform e Vault di HashiCorp verso la Business Source License. La motivazione dichiarata è sempre la stessa: un fornitore cloud offriva quel software come servizio gestito senza restituire nulla. Queste licenze non sono open source secondo la Open Source Definition della Open Source Initiative, la cui clausola 6 vieta di limitare l'uso in un campo di attività specifico. Un componente valutato come open source due anni fa può oggi comportare obblighi diversi, e il movimento non è a senso unico: Elasticsearch ha riaggiunto AGPLv3 nel 2024 ed è tornato open source. Il copyleft classico non si attiva quando il software è solo eseguito come servizio, perché non c'è distribuzione di copie: l'AGPL è la variante scritta per chiudere quella porta, e resta una licenza open source riconosciuta.

Un esempio enterprise

Una software house italiana ospita in cloud una piattaforma verticale per i propri clienti, costruita su un database adottato anni prima, quando era open source. Il progetto a monte cambia licenza: la nuova versione vieta di offrire quel prodotto come servizio gestito a terzi, che è esattamente ciò che la piattaforma fa. Le uscite sono tre, tutte costose: restare su una versione vecchia senza aggiornamenti di sicurezza, migrare a un fork della comunità, oppure negoziare una licenza commerciale. Nessuna riga di codice interna è cambiata, eppure il modello di ricavo dipende ora da una clausola scritta da qualcun altro.

Perché conta per chi decide

Sul lato proprietario il conto arriva da un'altra parte: per postazione, per core, per utente nominale o per ambiente, con la clausola di audit che consente al fornitore di verificare l'uso reale. Un ambiente di collaudo mai dichiarato o una macchina virtuale con più core del previsto diventano una fattura non prevista. Questa voce dà la mappa e l'economia; il rischio legale di contaminazione copyleft dentro un prodotto proprietario è trattato nel rischio delle licenze open source, e l'inventario dei componenti con la loro licenza è ciò che produce una SBOM.

Questa voce ha finalità informativa e non costituisce consulenza legale: la scelta di una licenza, o la valutazione di quelle già in uso, va fatta con un legale specializzato in proprietà intellettuale.