Negli ultimi anni diversi progetti molto usati hanno cambiato licenza, passando da licenze open source a licenze che permettono di leggere il codice ma ne limitano l'uso. Queste licenze sono spesso chiamate source-available: il sorgente è disponibile, ma non sono rispettate tutte le condizioni della Open Source Definition. Per chi sceglie un software, distinguere tra le due categorie è essenziale, perché le conseguenze pratiche sono molto diverse.
Cosa manca rispetto all'open source
La Open Source Definition, mantenuta dalla Open Source Initiative, richiede tra l'altro che la licenza non discrimini persone, gruppi o campi di attività. È proprio questo il punto su cui le licenze source-available si allontanano: vietano usi specifici, tipicamente offrire il software come servizio gestito in concorrenza con l'autore.
Un software può quindi avere il codice pubblico su un repository, accettare contributi e avere una comunità, ma non essere open source.
Le licenze più diffuse
Business Source License (BSL o BUSL)
La BSL è stata creata da MariaDB. Il suo funzionamento è caratteristico:
- il codice è leggibile e modificabile;
- l'uso in produzione è vietato o limitato, salvo quanto concesso in un campo chiamato «Additional Use Grant», che ogni progetto definisce a modo suo;
- dopo un periodo indicato nella licenza, a una Change Date, il codice di quella versione passa automaticamente a una licenza open source scelta dall'autore.
È un modello a scadenza: ogni versione resta riservata per un certo tempo, poi diventa libera. Nel 2023 HashiCorp ha adottato la BSL per diversi prodotti, tra cui Terraform.
Server Side Public License (SSPL)
Introdotta da MongoDB nel 2018, la SSPL somiglia all'AGPL, ma con un requisito molto più ampio: chi offre il software come servizio deve pubblicare sotto SSPL anche tutto il software usato per erogare quel servizio, come strumenti di gestione, monitoraggio, backup e interfacce. La SSPL è stata proposta alla Open Source Initiative e poi ritirata, senza approvazione; è generalmente considerata non open source.
Elastic License e simili
Altre licenze, come la Elastic License 2.0, sono più brevi e dirette: permettono uso e modifica, ma vietano di offrire il software come servizio gestito e di aggirare le funzioni protette da chiave di licenza.
Perché le aziende le adottano
Le motivazioni dichiarate sono di solito economiche: un'azienda investe nello sviluppo di un progetto, e grandi fornitori cloud lo offrono come servizio a pagamento senza contribuire in proporzione. Cambiando licenza, l'azienda cerca di riservarsi il mercato del servizio gestito.
Cosa succede alla comunità
I cambi di licenza hanno spesso provocato fork, cioè copie del progetto mantenute a partire dall'ultima versione open source. Alcuni esempi noti:
| Progetto originale | Cambio di licenza | Fork open source |
|---|---|---|
| Terraform | verso BSL nel 2023 | OpenTofu |
| Redis | verso licenze source-available nel 2024 | Valkey |
| Elasticsearch | verso SSPL ed Elastic License nel 2021 | OpenSearch |
Il fork è possibile perché le versioni già pubblicate con licenza open source restano tali: una licenza non si può revocare retroattivamente su copie già distribuite.
Cosa significa per chi usa il software
Le domande da porsi sono concrete:
- Come lo uso? Per un uso interno, molte licenze source-available non pongono problemi. Per chi offre servizi gestiti a clienti, possono essere un ostacolo serio.
- Cosa dice l'Additional Use Grant? Nella BSL questo campo decide quasi tutto, e cambia da progetto a progetto.
- Chi accetta contributi? Spesso i contributi richiedono la firma di un accordo che consente all'azienda di rilicenziarli.
- Esiste un fork attivo? Se sì, conviene valutarne salute e compatibilità.
- Le versioni passate restano utilizzabili? Sì, alle condizioni con cui sono state rilasciate, ma senza aggiornamenti di sicurezza dal progetto originale.
Come riconoscerle
- La licenza non compare tra quelle approvate dalla Open Source Initiative.
- Il testo contiene restrizioni su servizi gestiti, concorrenza o uso in produzione.
- C'è una data futura che cambia la licenza.
- L'identificatore standard è diverso da quelli comuni: ad esempio
BUSL-1.1,SSPL-1.0oElastic-2.0.
Nel mio lavoro, quando valuto un componente per un cliente, segnalo sempre la differenza in modo esplicito: un «codice su GitHub» non è automaticamente una licenza open source.
In sintesi
- Le licenze source-available rendono visibile il codice ma vietano alcuni usi, quindi non sono open source.
- La BSL limita l'uso in produzione e converte ogni versione in open source dopo una data stabilita.
- La SSPL estende gli obblighi a tutto lo stack usato per offrire il servizio.
- I cambi di licenza hanno generato fork come OpenTofu, Valkey e OpenSearch.
- Prima di adottare un componente bisogna leggere le restrizioni d'uso, non solo verificare che il codice sia pubblico.
