Perché le licenze “permissive” non sono adatte per i software come LibreOffice ?

Le licenze “permissive” sono nate più o meno nello stesso periodo delle licenze copyleft, ovvero alla fine degli anni ottanta. La prima è stata la BDS License, che è anche una delle più permissive nella versione con due sole clausole, anche se poi è nata la WTFPL (Do What The Fuck You Want To Public License) che è ancora più permissiva (come dice il nome, che in pratica significa “fai un po’ quello che ti pare”). Le più conosciute, oltre alla BSD License, sono la MIT License – nata nell’omonima università – e la Apache License.

Le licenze “permissive” hanno un ruolo importante nella storia del software libero, per cui il problema non è tanto quello di stabilire il loro valore (anche se io sono personalmente convinto del fatto che si tratti di licenze largamente inferiori a quelle copyleft, ma di questo ne parleremo nella prossima risposta) ma di capire se e quanto sono adatte a un progetto di software di produttività individuale come LibreOffice.

Contrariamente a quello che succede per la maggior parte dei progetti di software libero, LibreOffice ha una comunità composta solo in minima parte da tecnici e in larga parte da utenti del programma. Infatti, la maggior parte di coloro che si occupano di QA, localizzazione, documentazione, marketing e comunicazione ha un background completamente diverso, ed è quasi sempre arrivato al software da utente (così com’è successo al sottoscritto).

In realtà, anche un certo numero di sviluppatori – molti di quelli che si sono cimentati con gli “easy hack” – proviene dal novero degli utenti, e a un certo punto ha scelto di cimentarsi con la programmazione perché stimolato dalla possibilità di contribuire a migliorarlo.

Nel complesso, credo sia possibile affermare che circa il 90% della comunità di LibreOffice proviene dal mondo degli utenti, e che nella – quasi – totalità dei casi si tratta di volontari indipendenti (come il sottoscritto) che contribuiscono perché si divertono e imparano qualcosa di nuovo. La licenza copyleft contribuisce alla creazione di una situazione simmetrica in cui ciascuno contribuisce secondo le proprie risorse (personali o aziendali) senza che l’azienda possa prevaricare l’individuo perché è più forte.

Questa situazione simmetrica, ovviamente, è del tutto teorica, in quanto ci sono persone e aziende che contribuiscono in modo molto più importante, ma basta per creare un clima di collaborazione (in quanto nessuno si mette a contare quello che ha fatto, e a confrontarlo con quello che hanno fatto gli altri).

Certo, quando alla guida del progetto c’è una sola azienda, come nel caso di Sun con OOo, la situazione simmetrica è sbilanciata a favore dell’azienda, anche se poi viene accettata dalla maggior parte dei volontari (peraltro, fino a un certo punto, in quanto si rischia sempre di superare il limite, cosa che Sun ha fatto più volte con il Community Council di sette membri, di cui tre eletti da Sun e tre dalla comunità, dove il Community Manager stipendiato da Sun aveva il voto decisivo, per cui le votazioni finivano sempre quattro a tre).

Per evitare il ripetersi di questa situazione, The Document Foundation ha creato uno sbarramento al 30% dei voti all’interno di tutti gli organismi decisionali, che è un ulteriore strumento di difesa dei volontari indipendenti rispetto alle aziende. Lo sbarramento riguarda il Board of Directors, il Membership Committee e l’Engineering Steering Committee.

Quindi, la licenza copyleft è solo uno degli elementi dell’equazione, ma è il più importante in quanto protegge il patrimonio della fondazione, ovvero il software.

Pochi lo sanno, ma OOo 1.1 era rilasciato anche con la licenza permissiva SISSL. Ora, i sostenitori delle licenze “permissive” affermano che queste costituiscono un motivo di attrazione per le aziende, che in virtù della licenza permissiva corrono a frotte per offrire i propri contributi. Orbene, la storia dimostra che c’è una sola azienda che offre i propri contributi in funzione della licenza permissiva: IBM. Le altre non hanno problemi a contribuire sulla base della licenza copyleft.

IBM ha sviluppato Symphony a partire dal codice di OOo 1.1 – che era un’antologia di bug – fino a quando, nel 2008 (quando c’era già OOo 3.0, per cui il codice della 1.1 era protostorico), ha firmato un contratto con Sun che le dava il diritto di ignorare i vincoli della licenza copyleft per poter produrre un programma proprietario, ovvero la nuova versione di Symphony che conteneva già la sidebar e il codice di accessibilità sbandierati da Apache OpenOffice come novità.

Quindi, la storia corregge i sostenitori delle licenze “permissive” e rivela che queste – se applicate al codice di OOo, e probabilmente al codice di qualsiasi altro software di produttività (non esistono dati in tal senso, ma l’esempio di OOo è una prova indiziaria) – attraggono solo IBM. Il bello è che non attraggono nemmeno i volontari, con l’esclusione dei talebani delle licenze “permissive” (vedremo una serie di esempi illustri), dei nostalgici di OOo e degli amici di IBM.

E’ sempre antipatico fare un confronto sui numeri, per cui rimando i curiosi a GITHub (LibreOffice: https://github.com/LibreOffice/core/pulse/monthly, Apache OpenOffice: https://github.com/apache/openoffice/pulse/monthly). In questo caso, i numeri e le immagini valgono più di qualsiasi commento.