Tra le licenze permissive, che lasciano fare quasi tutto, e la GPL, che estende il copyleft all'intero programma derivato, esiste una via di mezzo: il copyleft debole. L'idea è semplice. La libreria resta libera, e chi la migliora deve condividere i miglioramenti; ma il programma che la usa può avere una licenza diversa, anche proprietaria. Le due licenze più usate di questo tipo sono la GNU Lesser General Public License (LGPL) e la Mozilla Public License 2.0 (MPL). Raggiungono lo stesso obiettivo con meccanismi molto diversi.
LGPL: il confine è la libreria
La LGPL ragiona in termini di libreria e di applicazione che la usa. Le modifiche alla libreria devono restare sotto LGPL. L'applicazione che si collega alla libreria, invece, può avere qualsiasi licenza, a patto di rispettare alcune condizioni.
Collegamento dinamico e statico
La distinzione pratica più importante riguarda il modo in cui la libreria viene unita al programma.
- Collegamento dinamico: la libreria è un file separato (una
.sosu Linux, una.dllsu Windows) caricato all'avvio. È lo scenario più semplice: l'utente può sostituire la libreria con una versione modificata senza toccare l'applicazione. - Collegamento statico: la libreria viene incorporata nell'eseguibile. È ammesso, ma chi distribuisce deve permettere all'utente di ricollegare l'applicazione con una versione modificata della libreria, ad esempio fornendo i file oggetto dell'applicazione.
Il principio di fondo è che l'utente deve poter sostituire la parte LGPL con una propria versione. Per lo stesso motivo la LGPLv3 richiede di non vietare, nei termini d'uso, il reverse engineering necessario a fare il debug di tali modifiche.
Cosa va consegnato
Chi distribuisce un'applicazione che usa una libreria LGPL deve, in sintesi:
- segnalare che la libreria è usata e che è coperta dalla LGPL;
- fornire il testo della licenza;
- rendere disponibile il sorgente della libreria, comprese eventuali modifiche;
- consentire la sostituzione della libreria come descritto sopra.
MPL 2.0: il confine è il file
La MPL 2.0, pubblicata nel 2012, adotta un criterio diverso e molto concreto: il copyleft si applica file per file. Se modifichi un file rilasciato sotto MPL, quel file modificato resta sotto MPL e il suo sorgente va reso disponibile quando distribuisci. I file nuovi che scrivi tu, anche se compilati insieme agli altri nello stesso eseguibile, possono avere la licenza che preferisci.
Questo rende la MPL facile da applicare: per sapere cosa va pubblicato basta guardare quali file con intestazione MPL sono stati toccati. Non serve stabilire se un componente sia «collegato» o «derivato».
Compatibilità con la GPL
La MPL 2.0 contiene una clausola sulle «licenze secondarie»: salvo che l'autore abbia marcato il codice come «Incompatible With Secondary Licenses», il codice MPL può essere combinato in un'opera più ampia distribuita sotto GPL, LGPL o AGPL. È stato uno dei cambiamenti più importanti rispetto alla versione precedente.
Confronto rapido
| Aspetto | LGPL | MPL 2.0 |
|---|---|---|
| Unità del copyleft | la libreria | il singolo file |
| Software proprietario che la usa | ammesso | ammesso |
| Collegamento statico | ammesso, con possibilità di ricollegare | nessun requisito specifico |
| Modifiche alla parte libera | sotto LGPL, sorgente disponibile | sotto MPL, sorgente dei file disponibile |
| Compatibilità con GPL | sì | sì, salvo marcatura contraria |
| Concessione brevetti | nella v3, tramite GPLv3 | sì, esplicita |
Quando usarle
La LGPL è adatta a librerie che si vogliono rendere utilizzabili da qualsiasi programma, mantenendo però libera la libreria stessa. È stata scelta da molte librerie di sistema e multimediali proprio per permettere il loro uso diffuso.
La MPL è adatta a progetti in cui l'azienda vuole permettere estensioni proprietarie, ma desidera che le correzioni al nucleo tornino pubbliche. È anche comoda nei progetti che mescolano molti linguaggi o sistemi di build, dove il concetto di «collegamento» è sfumato.
Esempio pratico
Un'azienda sviluppa un programma di fotoritocco proprietario e usa una libreria di decodifica immagini.
- Se la libreria è LGPL e viene distribuita come file dinamico separato, l'azienda include licenza e sorgente della libreria, e il programma resta chiuso. Se corregge un bug nella libreria, pubblica la correzione.
- Se la libreria è MPL e l'azienda modifica due file del decoder, pubblica quei due file modificati. Il resto del programma, compresi i nuovi file che chiamano il decoder, resta proprietario.
Nel mio lavoro, quando analizzo le dipendenze di un prodotto, le licenze di copyleft debole sono quelle che generano più domande: non sono difficili, ma richiedono di sapere esattamente come il componente viene compilato e distribuito.
In sintesi
- Il copyleft debole mantiene libera la componente, ma permette di usarla in software con altre licenze.
- La LGPL traccia il confine sulla libreria e richiede che l'utente possa sostituirla.
- La MPL 2.0 traccia il confine sul singolo file: si pubblicano solo i file MPL modificati.
- Entrambe sono compatibili con la GPL; per la MPL vale salvo marcatura contraria.
- Per applicarle bene bisogna conoscere il modo di collegamento e distribuzione del componente.
