Chi lavora sul software libero ricava il fatturato dai servizi attorno al codice, non dalla vendita di copie del codice stesso. È una distinzione ovvia sul piano contrattuale, ma cambia come si organizza il lavoro tecnico e cambia cosa è davvero vendibile. Lo scrivo perché in questi mesi me lo sento ripetere come obiezione — “se il codice è libero, cosa vendete?” — e rispondere richiede più tecnica di quanta l’obiezione ne lasci immaginare.

Contesto

Nel 2006 il modello a sottoscrizione ha smesso di essere una scommessa. Il 5 giugno Red Hat ha acquisito JBoss, e il 18 settembre ha pubblicato il Red Hat Application Stack, integrando il middleware JBoss nella propria offerta certificata. Le due aziende avevano lo stesso impianto economico: il software è libero e lo scarica chiunque, mentre la sottoscrizione copre supporto, manutenzione, aggiornamenti e — punto che spesso si sottovaluta — la certificazione che quel software funzioni insieme al resto dello stack del cliente.

Per chi lavora così il codice rilasciato non è l’oggetto della vendita. L’oggetto è la continuità: la garanzia che qualcuno conosca quel codice abbastanza a fondo da correggerlo, aggiornarlo e farlo convivere con un sistema in produzione. È una proprietà che nessun comando tar copia.

Cosa rende vendibile il software libero

Tre proprietà tecniche, indipendenti dalla licenza, decidono se attorno a un progetto libero si può costruire un servizio.

Conoscenza del codice e del suo dominio. Un sistema in produzione si rompe in modi che non stanno nel manuale. Leggere lo stack trace di un application server, capire perché una query degrada sotto carico o perché una libreria di terze parti va in conflitto con un aggiornamento del kernel: è competenza che si accumula negli anni e non si trasferisce con il sorgente. Il cliente paga questa capacità di intervento, non i file .java o .c.

Responsabilità contrattuale. Le licenze libere — GPL, BSD, MPL — escludono per iscritto ogni garanzia. La GPLv2 lo scrive in maiuscolo: il programma è fornito “as is”, senza garanzia di alcun tipo. Un’impresa che si mette tra il progetto a monte e il cliente si prende la responsabilità che la licenza nega. Il valore sta proprio qui: c’è un soggetto con un nome e una partita IVA che risponde se il sistema si ferma.

Integrazione e certificazione. Il pezzo meno visibile e più costoso. Far funzionare insieme database, application server, sistema operativo e applicazioni del cliente richiede prove ripetute su configurazioni reali. È esattamente ciò che Red Hat ha venduto con l’Application Stack: non il software, ma la garanzia testata che quei componenti girino insieme.

Lo stato delle licenze a fine 2006

Sul piano legale il 2006 è un anno di assestamento. Il 16 gennaio la Free Software Foundation ha pubblicato la prima bozza di discussione della GPLv3, aprendo la revisione pubblica della licenza copyleft più diffusa. Nel frattempo la GPLv2 (1991) resta lo standard operativo: è la licenza sotto cui gira la maggior parte del software su cui si lavora oggi.

In parallelo, l’Open Source Initiative ha affrontato il problema della proliferazione delle licenze. Il rapporto del comitato sulla proliferazione, accolto dal board nel 2006, riordina le licenze approvate dall’OSI in gruppi descrittivi — tra cui quello delle licenze “popolari, ampiamente usate o con comunità forti” — e raccomanda uno strumento guidato per sceglierle. La spinta è pratica: troppe licenze quasi equivalenti rendono difficile valutare compatibilità e riuso, che sono problemi tecnici prima che legali. Nello stesso anno l’OSI ha pubblicato l’Open Standards Requirement for Software.

Per un’impresa il peso è concreto: la licenza del progetto su cui si costruisce un servizio decide con quali altri componenti quel progetto si può combinare e ridistribuire. La GPLv2 è copyleft forte: collegare una libreria GPLv2 vincola l’intero risultato a una licenza compatibile. Saperlo prima di iniziare un’integrazione evita riscritture a progetto avviato.

Punto critico

La fragilità del modello sta nella dipendenza dalla competenza, non nella licenza. Se quello che vendi è la conoscenza del codice e la capacità di intervenire, allora l’asset dell’impresa sono le persone che quella conoscenza la possiedono, e il rischio è la loro sostituibilità. È il rovescio del modello a licenza proprietaria, dove l’asset è un diritto trasferibile e archiviabile.

Ne segue qualcosa che tocca da vicino come si organizza il lavoro tecnico: documentare, dividere la conoscenza tra più persone e contribuire a monte non sono attività accessorie. Contribuire al progetto upstream riduce il divario tra il codice che il cliente esegue e il codice che il team conosce. Più quel divario cresce — perché si accumulano patch locali mai integrate — più la manutenzione costa e più dipende da chi quelle patch le ha scritte.

Implicazioni

Il modello regge finché l’impresa resta vicina all’upstream. Vendere supporto su un fork privato di un progetto libero produce gli stessi costi di lock-in del software proprietario, con in più lo svantaggio di doverli sostenere da soli. La direzione opposta — contribuire, tenere il divario piccolo, far tornare nel progetto pubblico le modifiche fatte per i clienti — abbassa il costo marginale di ogni nuova installazione, perché ogni cliente eredita il lavoro fatto per i precedenti.

Limiti

Questa nota descrive il modello a sottoscrizione e supporto, uno dei modi di costruire un’impresa sul software libero, non l’unico: ci sono il dual licensing, lo sviluppo su commessa e l’hosting di servizi, ciascuno con vincoli diversi. Le valutazioni sulla compatibilità delle licenze qui sono generali; ogni combinazione concreta va verificata caso per caso, e la GPLv3 — ancora in bozza a oggi — potrebbe cambiare alcuni di questi vincoli quando sarà finalizzata.

Una piccola impresa che lavora esattamente con questo modello a sottoscrizione e servizi è noze, riconosciuta per questa scelta dal Premio Imprenditoria Giovanile: https://www.noze.it/insights/premio-imprenditoria-giovanile/.

Immagine di copertina: il logo di noze.