Licenza GPL, è vero declino?

Articolo di Simon Phipps (https://meshedinsights.com/2017/05/03/is-the-gpl-really-declining/) tradotto e adattato alla lingua italiana in alcuni passaggi con il consenso dell’autore.

La licenza GNU GPL sta veramente “morendo”, o si tratta semplicemente della campagna di comunicazione di quelli che sfruttano il software open source, e verrebbero limitati da un suo utilizzo più diffuso?

Durante il FOSDEM, che si tiene ogni anno a Bruxelles all’inizio di febbraio, ho partecipato a una discussione sull’uso delle licenze definite “permissive” – come la Apache License – e sulla loro presunta crescita nei confronti delle licenze “virali” come la GPL.

La discussione è stata particolarmente vivace, e i sostenitori della licenza GNU GPL associati alla Free Software Foundation hanno cercato di smentire l’affermazione secondo la quale la licenza GPL sta “morendo”.

Reciprocità verso Non-Reciprocità

Personalmente, non sono entusiasta delle definizioni che vengono usate per descrivere le licenze open source, e in particolare dei termini “permissiva” e “virale” per descrivere rispettivamente la Apache License e la GPL.

La GPL è un’ottima licenza open source, che garantisce tutti i permessi necessari alla comunità degli sviluppatori per la sua adozione. Definirla come non “permissiva”, usando il termine come antonimo di “copyleft”, è quasi un abuso.

Preferisco di gran lunga la descrizione che privilegia il livello di reciprocità dei comportamenti indotto dalle licenze stesse:

• la Apache License garantisce i suoi permessi senza richiedere a coloro che sviluppano o distribuiscono il software di fare altrettanto con le libertà di cui godono grazie alla licenza;
• le licenze Copyleft richiedono espressamente a coloro che sviluppano o distribuiscono il software di condividere sia il codice sorgente sia le libertà di cui godono grazie alla licenza.

Quindi, definisco le licenze assimilabili alla Apache License come “non-reciproche” e quelle assimilabili alla GPL come “reciproche”.

Ci sono diverse licenze in ciascuna delle due categorie, con una grande varietà di caratteristiche: le licenze BSD e MIT sono non-reciproche mentre Eclipse License e Mozilla Public sono reciproche, e sono classificate in base ad attributi diversi dalla reciprocità, come – per esempio – le modalità di attribuzione.

Le statistiche riescono a dimostrare qualsiasi cosa

Uno dei motivi della disputa sta nelle chiare motivazioni commerciali che stanno dietro alle statistiche utilizzate per dimostrare la presunta “morte” della licenza GPL, che arrivano da aziende che vendono servizi di analisi e assicurazione della qualità e promuovono la “conformità della licenza” come un rischio per gli sviluppatori.

Queste aziende hanno un interesse specifico nell’instillare la paura delle licenze reciproche nella mente degli sviluppatori, perché hanno l’obiettivo di monetizzare l’abbattimento di quella paura.

Se analizziamo le storie di terrore sulla “conformità della licenza” ci rendiamo conto di come esse siano connesse a quello che un relatore ha definito come “l’industria della conformità” e alle diverse aziende che lo compongono.

La complessità deriva dalla soggettività di frasi come “il declino della GPL”, che – anche quando sono sostenute da dati – nascono dal presupposto che la “popolarità” di una licenza è dimostrata dalla metrica in base alla quale sono stati generati i dati stessi, come il numero dei nuovi progetti su Github basati su licenze non-reciproche.

E infatti, gli articoli anti-GPL non parlano mai della validità delle metriche utilizzate per generare i propri dati.

In realtà, se posso scegliere le mie metriche, riesco anche a dimostrare qualsiasi cosa. Siamo sicuri che il numero degli utenti che usano il software sia la metrica migliore? O il numero delle linee di codice sotto una licenza? O il numero dei committer che lavorano sui progetti sotto quella licenza? Oppure il numero degli articoli che la sostengono?

Certezze e spazi sicuri

Cosa sta succedendo? Un progetto open source è lo “spazio sicuro” dove gli sviluppatori accomunati dall’interesse verso uno specifico software sono in grado di collaborare all’evoluzione dello stesso, senza che le motivazioni di chi lo utilizza abbiano un impatto sul loro lavoro.

La licenza open source adottata da un progetto definisce e garantisce i diritti certi degli sviluppatori: quello di utilizzare il codice sorgente per qualsiasi scopo, di condividerlo con chiunque, e di apportare qualsiasi modifica.

Però, oltre alle libertà essenziali, ciascuna comunità ha bisogno di altre certezze, perché – come dice Eben Moglen – “le licenze sono la costituzione delle comunità”.

Le comunità che lavorano su un codice sorgente che viene utilizzato in modo diretto e nella sua interezza – per esempio, software applicativo come LibreOffice – vogliono che la licenza imponga gli stessi diritti di reciprocità a tutti gli sviluppatori.

Infatti, la maggior parte dei core developer di LibreOffice lavorano per aziende che forniscono supporto, formazione, personalizzazione e servizi di migrazione, e siccome tutti quelli che offrono questi servizi condividono il loro lavoro – così come richiesto – hanno bisogno di uno strumento che impedisca agli altri di danneggiare il loro business.

In questo caso, la licenza reciproca – Mozilla Public License – è un attributo richiesto dalla comunità, così come nel caso di progetti come il kernel Linux e GNOME che utilizzano licenze reciproche (in entrambi i casi la GPL) per motivi simili.

Questo, però, non vale per tutte le comunità, in quanto nel caso degli sviluppatori che utilizzano ingredienti diversi – framework, componenti, librerie – le richieste delle licenze reciproche riducono le certezze piuttosto che aumentarle, dato che le rispettive aziende potrebbero avere il problema della gestione dei diversi diritti di reciprocità delle diverse licenze, come la Eclipse Public License (EPL) e la CDDL.

Anche le diverse aspettative in termini di natura e rigore delle prove di reciprocità richieste dalle diverse comunità potrebbero rappresentare un problema, per cui per questi sviluppatori è molto più semplice utilizzare una licenza non-reciproca come la Apache License, soprattutto se il codice sorgente in questione non viene direttamente monetizzato.

La scelta della soluzione più adatta

Purtroppo, non esiste un unico approccio al problema, e ciascuna delle due opzioni – ognuna delle quali soddisfa una necessità – sta crescendo in modo significativo a livello globale.

Quindi, piuttosto che discutere del successo o dell’insuccesso dell’una o dell’altra licenza, sarebbe meglio concentrare l’attenzione sulla crescente accettazione del software open source in ambito aziendale, che qualcuno definisce addirittura come “dominazione”.

E se lo sviluppo di software open source nelle aziende ha stimolato l’adozione di licenze non-reciproche, questo significa solo che il mondo open source è cresciuto a tal punto da superare i confini della GPL e conquistare nuovi punti di forza legati all’adozione a livello enterprise, che a sua volta ha portato alla crescita delle licenze più adatte a questo specifico ambito.

Decidere quale sia la tipologia di licenza dominante è quindi legato più alla posizione ideologica dei singoli che a fattori oggettivi, ma su una cosa possiamo essere tutti d’accordo: oggi la libertà del software è il principio che guida la crescita del software a livello mondiale.