“Open source” è una categoria di licenze, non un listino prezzi. La Open Source Definition, pubblicata dalla Open Source Initiative nel 1998, elenca i criteri che una licenza deve rispettare: libera ridistribuzione, codice sorgente disponibile, diritto di creare opere derivate, nessuna discriminazione verso persone o settori d’uso. Un programma può rispettarli tutti e farsi pagare; può violarne uno e girare gratis. Per una piccola azienda che deve decidere su cosa appoggiare la propria infrastruttura tecnica, questa è la prima distinzione da fissare.

Contesto

In due anni il software a sorgente aperto è uscito dai laboratori universitari ed è entrato nelle decisioni d’acquisto delle aziende. Apache è il web server più diffuso in rete da aprile 1996, secondo le rilevazioni mensili di Netcraft, e nel 1999 il gruppo che lo scrive si è dato una forma giuridica con la Apache Software Foundation. Nel gennaio 1998 Netscape ha annunciato l’apertura del codice del proprio browser, pubblicato poi a marzo sotto la Netscape Public License. Sul fronte finanziario, la quotazione di Red Hat ad agosto 1999 e quella di VA Linux a dicembre hanno portato il tema fuori dalla cerchia dei tecnici.

Per una piccola azienda questo vuol dire che uno stack a codice aperto — un sistema operativo derivato da Linux o da un BSD, Apache per il web, un linguaggio come Perl o Python, un database — oggi è una scelta concreta e documentata, non più una scommessa. La domanda non è più “funziona”, ma “a quali obblighi mi lego”.

Cosa dice la licenza

La licenza è il punto in cui si addensano le conseguenze pratiche. Conviene tenere distinte almeno tre famiglie.

Le licenze con copyleft, di cui la GNU General Public License versione 2 (pubblicata dalla Free Software Foundation nel giugno 1991) è l’esempio più diffuso, obbligano chi ridistribuisce il programma — o un’opera che ne deriva — a farlo sotto la stessa licenza, con il sorgente disponibile. L’obbligo scatta con la distribuzione, non con l’uso interno. Una piccola azienda che fa girare i propri sistemi su software GPL non deve pubblicare niente; deve farlo solo se consegna a terzi un programma derivato.

Le licenze permissive, come quelle in stile BSD o la licenza Apache, lasciano ridistribuire il codice anche dentro prodotti chiusi, in genere chiedendo solo di conservare l’avviso di copyright. Chi costruisce un prodotto proprietario su una base permissiva ha più margine per chiuderlo; chi contribuisce non ha alcuna garanzia che le sue modifiche restino aperte.

Le licenze ibride, come la Netscape Public License con cui è stato aperto il codice del browser, obbligano a condividere le modifiche al codice originale ma lasciano combinarlo con moduli proprietari separati.

Scegliere tra queste famiglie decide cosa si potrà fare del software fra tre anni, e a cosa saranno tenuti i fornitori su cui ci si appoggia. È una scelta operativa, non un’opzione etica.

Il punto critico: la dipendenza dal fornitore

Per una piccola azienda l’argomento tecnico più solido a favore del codice aperto è ridurre la dipendenza da un unico fornitore. Con il software proprietario, formati dei dati e protocolli li conosce spesso solo chi li produce; se quel fornitore chiude, ritocca i prezzi o abbandona il prodotto, l’azienda non ha una via d’uscita a basso costo. La Open Source Definition pretende sorgente disponibile e diritto alle opere derivate proprio per tenere aperta quella via d’uscita.

La conseguenza si tocca con mano. Se sparisce chi fornisce un sistema di posta a codice aperto, il codice resta, i messaggi restano leggibili, e un altro tecnico può riprendere la manutenzione. Questa proprietà vale anche quando il fornitore non sparisce: rende il rapporto meno sbilanciato, perché uscirne costa meno.

C’è il rovescio, e non è secondario: la responsabilità della manutenzione cambia mani. Con un contratto proprietario paghi qualcuno perché il sistema funzioni; con software a codice aperto adottato senza supporto, quel qualcuno deve esserci in casa o lo devi ingaggiare. Il sorgente disponibile è condizione necessaria per l’indipendenza, non sufficiente: per esercitarla serve competenza.

Cosa ne segue per chi sceglie

Per chi deve decidere oggi, alcune conseguenze sono immediate. Controllare la licenza vera di ogni componente prima di costruirci sopra, perché “si scarica gratis” e “licenza a sorgente aperto” non sono la stessa cosa. Tenere separato l’uso interno dalla ridistribuzione, perché gli obblighi di copyleft scattano sulla seconda. Valutare il fornitore di supporto separatamente dalla licenza: la licenza dice cosa puoi fare con il codice, il contratto di supporto dice chi risponde quando qualcosa si rompe.

Per una piccola azienda che dell’integrazione di software a codice aperto fa il proprio lavoro, c’è un effetto in più. Quello che vende non è il codice, che hanno tutti, ma la competenza nello sceglierlo, integrarlo, adattarlo e tenerlo in piedi. Su questo si regge il mercato del supporto e dell’integrazione attorno a Linux e ad Apache, che le quotazioni del 1999 hanno reso visibile. Su questa stessa scelta — competenza sull’integrazione a codice aperto venduta come servizio — è impostata noze, l’azienda costituita a Pisa attorno a uno stack Linux, Apache, Python e Zope, descritta nell’insight pubblicato da noze: https://www.noze.it/insights/costituzione-noze/.

Limiti

Quanto sopra riguarda le conseguenze contrattuali e operative dell’adozione, non la qualità tecnica dei singoli programmi, che va pesata caso per caso. L’elenco delle licenze approvate dalla Open Source Initiative è in movimento e nuove licenze sono in revisione; per capire quali requisiti valgono in un caso reale bisogna leggere il testo della licenza specifica, non un riassunto. I ragionamenti sulla dipendenza dal fornitore danno per scontato che competenze adeguate ci siano in casa o sul mercato locale, e a metà 1999 questa condizione non è uniforme dappertutto.

Immagine di copertina: Linus Torvalds, creatore del kernel Linux, ritratto in primo piano mentre parla — foto di autore sconosciuto, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Linus_Torvalds.jpeg