La GPL come strategia evolutiva

Di David Rysdam
Documento originale.
Traduzione di Andrea Glorioso

dal sito http://www.annozero.org/

In questo documento, propongo di prendere più seriamente l'analogia tra il mercato libero (in particolare il mercato del software) e la selezione naturale. Un buon modo per far ciò in maniera abbastanza rigorosa è di usare la nozione di "strategia evolutiva stabile" (SES). A questo scopo dobbiamo capire cosa sia una SES e come le licenze del software possano essere considerate delle strategie.

Così come viene usato in questo lavoro, il termine "strategia" proviene dalla teoria dei giochi. Un esempio rapido aiuterà a capire. Diciamo che A e B stanno giocando. Il gioco consiste nel correre l'uno contro l'altro all'interno di macchine lanciate ad alta velocità. La persona che sterza perde mentre la persona che non sterza vince. Se entrambi sterzano, nessuno vince. Se nessuno sterza, inutile a dirsi, entrambi perdono. Per rendere questa situazione più chiara mettiamo le strategie in una matrice e assegnamo dei valori numerici ad ogni risultato.

Questa è una "matrice dei risultati". Le righe sono le strategie disponibili per il giocatore A e le colonne sono le strategie disponibili per il giocatore B. I valori nelle celle sono i punteggi del giocatore A risultanti dalle strategie scelte sia da A che da B (potrebbero essere anche i risultati di B ruotando gli assi). I valori scelti sono arbitrari me la relazione tra di essi (-10 < -1 < 0 < 1) non lo sono. Ognuna delle celle corrisponde ad una delle seguenti proposizioni:
Se entrambi sterziamo non vince nessuno, il punteggio rimane 0.
Se l'avversario sterza e io no, vinco 1 punto.
Se io sterzo e l'avversario no, perdo 1 punto.
Se nessuno dei due sterza, moriremo entrambi e quindi perderemo 10 punti.
Da questo diagramma possiamo determinare quale dovrebbe essere la nostra strategia. Come? Appare chiaro che l'unico modo per A di guadagnare punti è di scegliere la strategia di non sterzare. Tuttavia questo è vero anche per il giocatore B. Ma se entrambi i giocatori scelgono la strategia di non sterzare sarebbe disastroso (per non dire esteticamente brutto). Dunque A, sapendo che B sceglierà di non sterzare, può decidere di minimizzare le proprie perdite scegliendo di sterzare. Ciò significa che otterrà -1 come punteggio, ma dato che -10 < -1 questo è un miglioramento sostanziale. Ovviamente B pensa la stessa cosa.

Ora consideriamo l'idea di una SES. Tutto ciò che dobbiamo fare è prendere il concetto di cui sopra e applicarlo ad una serie di sfide. In altre parole, A e B giocano l'uno contro l'altro diverse volte. Di fatto, abbiamo una grande popolazione di individui che non fanno niente tranne confrontare le proprie strategie l'uno con l'altro. Mentre giocano, gli individui raccolgono punti. Il punteggio relativo (non assoluto) di questi individui determina se sopravviveranno all'interno della popolazione. La SES è la strategia che alla fine domina all'interno della popolazione. È stabile nel senso che gli individui che scelgono un'altra strategia guadagneranno meno punti degli individui che scelgono la strategia SES.

Ci sono metodi matematici per scoprire quale sia l'SES date delle tabelle come quelle di cui sopra. Naturalmente esistono complicazioni come strategie miste e situazioni per cui non esiste alcuna SES tranne l'estinzione totale di tutti, ma non lo considereremo, almeno non in questa bozza.

Ora consideriamo le licenze del software come strategie. Per amor di brevità e di chiarezza consideriamo delle licenze estremamente (troppo?) semplificate. Una "tipica" licenza T, una generica licenza aperta O, ed una versione della GPL, G. Ecco delle sintesi di ciò che ogni licenza contiene:

T: Il codice sorgente non è disponibile per altri programmi.
O: Il codice sorgente può essere esaminato e incluso in altri programmi di qualsiasi tipo.
G: Il codice sorgente può essere esaminato e incluso solo in progetti con una licenza di tipo G.

Ora immaginiamo un universo di software popolato da molti programmi che eseguono essenzialmente lo stesso compito; ognuno dei programmi usa una delle licenze sopracitate come strategia. Esaminiamo cosa succede durante alcuni incontri di esempio per farci un'idea.
T1 incontra T2: T1 si dimostra superiore. Non è possibile per T2 esaminare il codice sorgente di T2 e quindi migliorarsi.
O1 incontra O2: O1 si dimostra superiore. O2 può esaminare il codice sorgente di O1 e incorporarlo. Al prossimo incontro (ricordiamoci che la SES prevede l'iterazione degli incontri) O1 e O2 sono più o meno simili.
G1 incontra O1: G1 si dimostra superiore: O1 può esaminare il codice sorgente di G1 ma non può includerlo senza cambiare le proprie strategie.
E così via. Ovviamente ci sono nove possibile coppie di interazioni ma possiamo riassumerle in una matrice dei risultati come sopra. Diciamo che essere in grado di usare il codice del vostro avversario vale 10 e che qualcun altro usi il proprio codice valga -5 (si ricordi che il punteggio assoluto non è importante, solo i punteggi relativi).

Come promemoria per leggere questo schema, facciamo un esempio concreto: quando un programma con licenza T (la prima riga) incontra un programma con licenza T, non c'è alcuno scambio di codice e dunque il punteggio è 0. Se T incontra O, T usa il codice di O, guadagnando 10 punti. Se T incontra G, non c'è nessuno scambio - niente punti.

La caratteristica più ovvia di questo diagramma è che i programmi che usano la strategia O sono "prede" di T e di G. Secondo la terminologia della teoria dei giochi essi sono dei "parassiti". La ragione di ciò risiede nelle definizione della strategia O. Tutti i giocatori possono esaminare e usare il codice dei programmi con strategia O ma questi ultimi possono usare il codice solo di altri programmi O. Di fatto i programmi con strategia O cooperano bene gli uni con gli altri, ma non impediscono ai "predatori" di abusare di loro.

La seconda caratteristica è che i programmi con strategia T sono invulnerabili all'abuso subito dai programmi O. Poiché non rendono il codice sorgente disponibile non c'è alcuna possibilità che si abusi della loro generosità. D'altra parte questo blocca la possibilità di cooperare. I programmi T non vengono uccisi dagli altri, ma non si assistono nemmeno l'uno con l'altro. Ciò è l'opposto dei programmi O.

Una caratteristica sottile è che i programmi con strategia G combinano il meglio di entrambi i mondi. I G cooperano bene perché il codice sorgente è disponibile ma non possono diventare prede dei non G a causa della restrizione sull'utilizzo del codice solo da parte di altri programmi G. In altre parole, i G cooperano solo con i programmi che sicuramente cooperano in cambio. Chi ha familiarità con il Dilemma del Prigioniero può riconoscere in ciò una variazione della classica strategia "pan per focaccia".

Cosa significa ciò nel lungo periodo (all'interno del nostro universo giocattolo popolato da software)? Inizialmente i T e i G cresceranno rapidamente a spese di O. Dopo un po', però, gli O si estinguiranno man mano che il punteggio medio dei programmi O diventa molto più basso di quello dei T e dei G (si ricordi che l'esistenza nel gioco è determinata dal punteggio relativo). Una volta che gli O sono scomparsi la matrice dei risultati si riduce alla seguente:

Questa matrice dei risultati è estremamente semplice e chiara. Né T né G guadagneranno alcunché l'uno dall'altro, ma i G sopravanzeranno i T perché i G cooperano tra di loro mentre i T non lo fanno. Alla fine i T si estingueranno e tutti i programmi nell'universo (giocattolo) seguiranno una strategie di tipo G.

Sono possibili molte obiezioni a questo modello. Alcune di queste obiezioni vengono espresse qui con le relative risposte.

Obiezione
T, O e G sono più semplici delle vere licenze.
Risposta
Ciononostante svolgono adeguatamente la loro funzione, cioè illustrare l'idea di "licenze come strategie". E se confrontiamo le previsioni derivanti da questo modello, pur nella sua semplicità, con la storia dell'industria del software si troveranno dei paralleli.

Obiezione
T, O e G non rappresentano tutte le possibili strategie. Ognuna di esse ha dei sottotipi e si possono creare degli altri tipi.
Risposta
È vero. Ma penso che si possa essere d'accordo che la forza della licenza G è la combinazione della cooperazione insieme alla difesa contro i predatori. Perlomeno abbiamo mostrato come G è meglio di T. Può essere che G si dimostrerà dopo più debole di X (la sconosciuta superlicenza futura)

Obiezione
Questo modello assume che tutti i programmi dell'universo svolgano la stessa funzione. Ma ci sono molti tipi di programmi, dai sistemi operativi ai word processor ai giochi con le carte.
Riposta
È sufficiente assumere che tutti i programmi svolgano la stessa funzione. È facile capire perché. Supponiamo che ci siano due tipi di software. Possiamo creare due universi come modello, uno per ognuno dei tipi di programmi che esistono. Ciò riduce la situazione a quella descritta in questo articolo. Lo stesso può essere fatto per qualsiasi numero di differenti tipi di programmi. La ragione per cui questo ragionamento funziona è che i software, solitamente, non competono tra tipi diversi.

Obiezione
I programmi di ogni tipo di licenza non devono barare, o almeno non troppo. Per esempio, se i programmi T incorporano codice dai programmi G nonostante la licenza, T otterrà i benefici della cooperazione senza pagare il prezzo di essere vulnerabile ai predatori.
Risposta
Anche assumendo che non esistano leggi a protezione del copyright, ciò è vero solo all'inizio. Man mano che G comincia a sopravanzare T nell'universo, i T sopravvissuti verranno visti con sempre maggior sospetto. La gente si chiederà: "Come mai questi T sopravvivono senza condividere il codice sorgente?". Si potrebbe scoprire ben presto che non lo fanno. Un'altra risposta risiede nella natura continuativa della cooperazione. Se pochi T solitari fossero in grado di beffare la legge e rubare codice questo guadagno sarebbe solo un atto singolo che dovrebbe essere ripetuto nel tempo man mano che la preda (un programma G o O) continua a progredire.

Obiezione
Se un universo pieno di licenze G non può essere invaso da licenze T, come si spiega la crescita di licenze T nel mondo reale durante gli anni '80?
Risposta
Le licenze T degli anni '80 non stavano invadendo un universo pieno di G. Stavano invadendo un universo di O. Abbiamo già visto quanto gli O siano vulnerabili ai predatori e la storia di fatto indica che molte aziende di software hanno cominciato rubando codice disponibile pubblicamente (o almeno non pesantemente protetto) e vendendolo come proprio.

Obiezione
Che dire dell'economia dell'industria del software? Le aziende, per esempio, fanno ciò che rende loro denaro. Le licenze T offrono una possibilità migliore di far ciò perché proteggono la proprietà intellettuale.
Risposta
Le aziende possono fare denaro solo sui programmi che sopravvivono sul mercato. Un punto sottile circa la discussione di cui sopra è che il principale beneficiario di una licenza G è il
programma che la usa. Si parla sempre di quanto bello sia avere accesso al codice sorgente di un programma e pensiamo che questa sia la ragione per scegliere una licenza aperta. Ma la matrice dei risultati indica che il vantaggio principale è per il programma in sé. Una volta le aziende avranno capito questo concetto di "egoismo illuminato" cambieranno strategia. E questa comprensione sarà facile una volta che avranno visto le strategie T scomparire, ma la competizione che rimane.

Obiezione
La matrice dei risultati presuppone che, prima del primo turno di confronti, tutti i programmi siano distribuiti in modo casuale lungo la curva della performance. Ovvero che due programmi A e B scelti a caso abbiano eguali possibilità di dimostrarsi superiori. Ciò potrebbe non essere vero nel mondo del software reale. Se invece i programmi con licenza T fossero, per qualsiasi motivo, sempre migliori dei programmi con licenza G e T, non importerebbe molto quanto G ruba da O o coopera con altri G - non riuscirebbero a raggiungere i T.
Risposta
In primo luogo non c'è alcun reale motivo per suppore che una qualche licenza di tipo L produca programmi migliori. Ma diciamo per amore della discussione che lo siano. Non cambierebbe nulla. I miglioramenti nel software non vengono ottenuti soltanto tramite la predazione - la maggior parte di essi è dovuto allo sforzo extra delle persone responsabili. E se questo è il caso, tutto ciò che occorre dimostrare è che i programmatori che lavorano su programmi non L sono mediamente uguali a quelli che lavorano ai programmi L. Tornando nel mondo reale, la domanda diventa: "I programmatori che usano la GPL sono più o meno uguali ai programmatori che usano licenze proprietarie?". La risposta è ovvia: molti di questi programmatori sono le medesime persone!

Obiezione
Uno dei punti fondamentali della precedente risposta è che T siano predatori non cooperanti. Ma in realtà le aziende di software lavorano insieme per condividere delle idee.
Risposta
Questo è assolutamente vero. Ma ci vuole un atto coscio da parte dei vari T per cooperare tra di loro. Per i vari G la cooperazione è automatica, il che la rende più diffusa. Il potere di G sta nel fatto che la cooperazione è innata, mentre quella degli T è forzata.

Obiezione
Posso capire perché usare codice di un altro programma fa guadagnare punti. E capisco perché non poterlo fare non fa guadagnare punti. Ma perché si perdono dei punti se qualcun altro usa il mio codice? Di certo il costo per me è trascurabile.
Risposta
Questo è un argomento difficile da contrastare. Bisogna capire che il costo per me se qualcuno usa il mio codice non deve essere alto: "trascurabile" è sufficiente. Finché quel valore è anche solo leggermente più alto che se non usassero il codice la relazione tra i punteggi rimane la stessa: ci vuole solo più il tempo perché il mio punteggi cali e io mi estingua. Quindi tutto ciò che è necessario sono delle ragioni, per quanto piccoli, per cui il fatto che qualcuno usi il mio codice senza darmene beneficio mi costi un piccolo ammontare di energia/denaro/tempo. È questo il caso? Io credo che lo sia, ma non ho dati sostanziali da presentare al momento.

Obiezione (grazie a Nicholas FitzRoy-Dale)
"... mi pare che si ignori il fatto che la sorgente primaria per lo sviluppo di codice in un nuovo programma non è mai il codice di altre persone. Quando due T si incontrano, c'è spesso un beneficio per entrambi, perché ciò che è importante non sono le linee di codice dietro ad un programma (che chiunque può scrivere) ma le idee... se si hanno le risorse per essere in grado di riutilizzare le idee dei programmi G, allora i programmi T possono essere migliorati senza lo "svantaggio" di dover condividere il proprio codice - nemmeno con gli altri G".
Risposta
Si assume che il costo principale sia quello di "capire cosa aggiungere". Se posso ottenere le mie idee da altri programmi senza usare il loro codice, sono in testa alla gara. Eccetto che ci vuole ancora molto tempo per l'implementazione e la manutenzione nel lungo periodo. Se si prende l'idea (ma non il codice) per un controllore ortografico da un prodotto esistente si è eliminato il costo della condivisione. Ma si è anche eliminato il risparmio di avere il manutentore originale che fa tutto il "lavoro sporco" e la manutenzione (correzione dei bachi, etc). Questo è esattamente il motivo per cui le aziende basate su T cercano di trovare "pacchetti" e librerie che svolgeranno compiti ben definiti come controllo ortografico, gestione di LDAP, accesso ai database e così via.

Così ora siamo preparati a rispondere ad una domanda di base che è stata posta recentemente. Il software Open Source (OSS) è un fenomeno transitorio o no? L'OSS ha preso piede rapidamente e questo articolo fornisce dei fondamenti matematici ragionevolmente fermi per una spiegazione del perché. Le licenze GPL (e equivalenti) quando considerate come strategie, sono semplicemente meglio adatte al libero mercato. In altre parole, l'OSS è qui per restarci.

NB: alcuni mi hanno chiesto di chiarire la confusione che posso aver causato. Prima di tutto l'analisi di cui sopra fornisce solo degli argomenti circa l'efficacia, non la moralità. C'è chi pensa che, anche se le licenze O e G non fossero meglio per il software, sono meglio per le persone. In secondo luogo si noti che "Software Open Source" e "Software Libero" non sono termini intercambiabili. Parlando in generale i due termini riguardano le stesse licenze sul software ma per ragioni diverse. "Software Libero" è un termine coniato dalla Free Software Foundation (www.fsf.org) nel 1985 per promuovere il concetto morale della libertà. "Software Open Source", un'invenzione più recente non connessa con FSF, si occupa quasi esclusivamente degli aspetti pragmatici del rendere il codice sorgente disponibile agli utenti e ai programmatori.