GitHub sotto accusa: perché GNU invita gli sviluppatori a lasciarlo

La posizione dominante di una piattaforma come GitHub nella distribuzione del codice sorgente solleva una questione che spesso passa in secondo piano: fino a che punto può condizionare lo sviluppo del software libero? Free Software Foundation (FSF) affronta il problema con una critica particolarmente severa, sostenendo che GitHub abbia progressivamente introdotto meccanismi capaci di limitare l’autonomia degli sviluppatori, nonostante utilizzi Git, uno strumento nato proprio per garantire indipendenza e decentralizzazione.

Le obiezioni arrivano da Jacob Bachmeyer e Richard Stallman, fondatore del progetto GNU, che invitano esplicitamente gli sviluppatori a evitare GitHub come piattaforma principale per ospitare i progetti. Le motivazioni non riguardano soltanto la proprietà del servizio, oggi controllato da Microsoft, ma investono aspetti tecnici molto concreti: gestione delle licenze, esecuzione di JavaScript proprietario, dipendenza da servizi remoti, automazione dello sviluppo e progressiva centralizzazione dei processi di collaborazione.

Git nacque nel 2005 per iniziativa di Linus Torvalds, dopo la controversia che portò gli sviluppatori del kernel Linux ad abbandonare BitKeeper, un sistema di controllo versione proprietario. GitHub arrivò nel 2008, semplificando enormemente la pubblicazione e la collaborazione sui repository Git. Microsoft acquisì la società nel 2018 per 7,5 miliardi di dollari. Da allora, il servizio ha ampliato le proprie funzionalità fino a comprendere strumenti di integrazione continua, gestione dei progetti e assistenza alla programmazione mediante intelligenza artificiale.

Git è distribuito, GitHub concentra le attività su un unico servizio

Git utilizza un modello di controllo versione distribuito: ogni clone completo di un repository contiene gli oggetti e la cronologia necessari per lavorare autonomamente sui riferimenti acquisiti. Non serve collegarsi continuamente a un server centrale per consultare i commit, creare nuovi branch, analizzare le differenze o registrare modifiche.

Un repository locale contiene gli oggetti Git, conservati in una struttura che identifica i contenuti mediante hash crittografici. Il riferimento a un server remoto, normalmente chiamato origin, rappresenta una convenzione operativa, non un elemento imposto dall’architettura.

Nulla vieta a uno sviluppatore di utilizzare più server Git contemporaneamente, distribuire modifiche via email oppure scambiare bundle tra macchine completamente isolate.

GitHub ha conservato la compatibilità con i meccanismi alla base di Git ma ha costruito attorno ai repository una serie di funzionalità che spingono gli utenti a svolgere quasi tutte le operazioni all’interno della piattaforma. Il caso più evidente riguarda le pull request.

Git permette di recuperare commit da qualunque repository raggiungibile e integrarli localmente mediante fetch, merge oppure rebase. GitHub, invece, organizza la revisione del codice attraverso un servizio che richiede di utilizzare repository e branch accessibili all’interno della propria infrastruttura. Il codice rimane portabile; gran parte del lavoro collaborativo, invece, resta legato alle strutture applicative del fornitore.

Il problema delle licenze: un repository pubblico non è necessariamente software libero

La seconda parte della critica mossa da FSF riguarda le licenze: GitHub permette di pubblicare repository pubblici senza specificare alcuna licenza software, una possibilità perfettamente legittima ma spesso fraintesa dagli sviluppatori meno esperti.

Rendere visibile il codice non significa autorizzarne automaticamente la modifica, la ridistribuzione o il riutilizzo. In assenza di una licenza esplicita, continuano ad applicarsi le normali regole sul diritto d’autore, salvo le autorizzazioni specifiche previste dalle condizioni della piattaforma.

GitHub chiarisce il principio nella propria documentazione sulle licenze dei repository; la piattaforma offre inoltre il servizio Choose a License, introdotto nel 2013 per aiutare gli autori a selezionare una licenza adatta al proprio progetto.

Secondo FSF, però, GitHub offrirebbe indicazioni fuorvianti su come applicare correttamente la licenza GNU GPL a un progetto software. Bachmeyer e Stallman sostengono che GitHub suggerisca una procedura troppo semplicistica: inserire una copia integrale della GPL in un file LICENSE o COPYING all’interno del repository, presentando tale operazione come sufficiente per distribuire il programma sotto quella licenza.

Per GNU, il problema è che GitHub considera facoltativa una precauzione che FSF ritiene essenziale: aggiungere in ogni file sorgente significativo una dichiarazione che identifichi chiaramente la licenza applicabile, il titolare dei diritti e le condizioni relative alle versioni successive.

L’accusa della FSF a GitHub è dunque quella di favorire involontariamente la proliferazione di repository con condizioni di utilizzo insufficientemente precise, anziché guidare gli sviluppatori verso dichiarazioni inequivocabili.

Codice JavaScript proprietario e il controllo sulle operazioni eseguite nel browser

FSF punto il dito anche contro il funzionamento dell’interfaccia Web di GitHub, che richiede l’esecuzione di quantità significative di codice JavaScript per accedere alle funzionalità più avanzate.

Dal punto di vista del movimento del software libero, il codice JavaScript rappresenta software eseguito sul computer dell’utente, esattamente come un programma tradizionale.

Se gli script risultano proprietari oppure non soddisfano i requisiti delle licenze libere, chi visita il sito non dispone necessariamente delle libertà di studiarli, modificarli e redistribuirli: Stallman affronta il problema nella sua analisi The JavaScript Trap.

Disabilitando JavaScript, diverse funzionalità di GitHub diventano inutilizzabili o perdono capacità operative: la semplice consultazione di alcune risorse può ancora funzionare, ma l’esperienza complessiva dipende sempre più dal codice eseguito lato client.

GNU contesta però anche l’approccio del client ufficiale GitHub CLI, distribuito come software libero sotto licenza Expat, per l’introduzione di funzionalità di telemetria.

GitHub Copilot e il software che lavora su server controllati da altri

Con l’introduzione di GitHub Copilot nel 2021, il rapporto tra sviluppatori e piattaforma si è ulteriormente trasformato: un servizio inizialmente concepito per suggerire frammenti di codice si è trasformato progressivamente in uno strumento capace di analizzare repository, proporre modifiche articolate, assistere nelle revisioni e svolgere attività di programmazione attraverso agenti AI.

GNU affronta Copilot attraverso il concetto di SaaSS (Service as a Software Substitute), un’espressione coniata dalla FSF per descrivere situazioni nelle quali un utente affida a un servizio remoto elaborazioni che potrebbe altrimenti controllare mediante un programma eseguito sul proprio computer.

L’obiezione principale riguarda la mancanza di controllo sui componenti che eseguono realmente il lavoro: modelli, configurazioni, versioni disponibili, risorse computazionali e modalità operative dipendono dal fornitore. Una modifica introdotta lato server, secondo FSF, può alterare il comportamento del sistema senza che l’utente disponga della possibilità di continuare a utilizzare esattamente la versione precedente. Anche i criteri commerciali possono cambiare, incidendo sui costi delle operazioni e sull’accessibilità delle funzionalità.

Come trasferire un progetto GitHub senza perdere il lavoro accumulato

La critica della FSF conduce a una domanda pratica: quanto è difficile trasferire un progetto su un’altra piattaforma?

Per il codice sorgente, l’operazione è semplice: utilizzando git clone --mirror si ottiene una copia dei riferimenti Git disponibili tramite il protocollo; il comando git push --mirror permette poi di pubblicarli su un nuovo repository remoto.

Attenzione, però: un mirror Git non rappresenta un backup completo di GitHub. La procedura non trasferisce automaticamente issue, commenti, discussioni, pull request con le relative revisioni, impostazioni di protezione dei branch, segreti, configurazioni dei runner e altre informazioni gestite separatamente dal servizio.

La migrazione completa richiede comunque un inventario di tutte le funzionalità utilizzate, un’esportazione verificabile dei dati e una procedura per ricostruire le relazioni essenziali.

FSF cita anche servizi di hosting alternativi. Tra le possibilità figurano soluzioni differenti per architettura, strumenti di collaborazione e modalità di gestione:

• GNU Savannah rappresenta una scelta particolarmente coerente con le posizioni della FSF. Il servizio ospita progetti software liberi e segue regole specifiche sulle licenze ammissibili. Non nasce per offrire tutte le comodità di GitHub, ma privilegia la conformità ai principi del progetto GNU.
• SourceHut propone un’impostazione maggiormente orientata a strumenti essenziali e collaborazione tramite email. L’integrazione tra repository, mailing list e sistemi di build permette di lavorare senza riprodurre necessariamente il modello delle pull request tipico di GitHub.
• Forgejo offre invece un software libero per realizzare una piattaforma Git autonoma, dotata di gestione dei repository, issue e revisioni del codice. Può essere installato su infrastrutture proprie, consentendo all’organizzazione di controllare direttamente gli aggiornamenti, l’archiviazione e l’accesso ai dati.
• Codeberg utilizza Forgejo per offrire un servizio di hosting rivolto soprattutto ai progetti software liberi. Rappresenta una soluzione accessibile per chi desidera allontanarsi da GitHub senza dover amministrare un server.

La valutazione dei servizi di hosting FSF prende in considerazione requisiti molto rigorosi, inclusi quelli relativi al JavaScript eseguito nei browser e alla disponibilità del codice delle applicazioni Web.

La vera questione non è GitHub, ma chi controlla lo sviluppo del software

Il documento di Bachmeyer e Stallman propone una lettura radicale: una piattaforma che ospita software libero può contribuire a limitarne le libertà quando concentra su di sé strumenti indispensabili per lo sviluppo, la collaborazione e la distribuzione.

Alcune critiche mosse a GitHub, come abbiamo visto, riguardano scelte etiche, come il rifiuto del JavaScript proprietario o della telemetria; altre identificano dipendenze tecniche misurabili. GitHub non rende proprietario un programma distribuito sotto licenza libera e non impedisce agli sviluppatori di utilizzare Git indipendentemente dai suoi server. Può però rendere sempre più oneroso trasferire altrove le attività che circondano il codice.

Mettendo da parte qualunque riserva ideologica, va detto che possedere una copia del codice non significa disporre di tutte le informazioni necessarie per continuare a svilupparlo.

Un progetto conserva una reale autonomia quando può cambiare fornitore senza compromettere cronologia, processi di compilazione, comunicazioni e capacità di accettare contributi. Git lo permette per sua natura. Sta agli sviluppatori evitare che gli strumenti costruiti intorno a Git trasformino tale libertà in una possibilità soltanto teorica.