Richard Stallman e il software libero: idee che hanno cambiato il codice

Perché Richard Stallman conta ancora

Il software non è solo un prodotto tecnico: è anche un insieme di permessi. Chi può eseguirlo, copiarlo, condividerlo con un amico, correggere un bug o costruire qualcosa sopra? A queste domande risponde meno il codice e più la licenza. Quando il software è diventato centrale per lavoro, comunicazione e ricerca, le regole su “cosa ti è permesso fare” hanno cominciato a modellare l'innovazione quanto le funzionalità.

Richard Stallman (spesso chiamato “RMS”) conta perché ha reso impossibile ignorare quelle regole. All'inizio degli anni ’80 vide un cambiamento: sempre più programmi venivano distribuiti senza codice sorgente e agli utenti si diceva che potevano usare il software solo secondo i termini imposti da altri. Stallman inquadrò questo non come un fastidio, ma come una perdita di libertà per utenti e sviluppatori — e rispose proponendo principi chiari e strumenti legali per proteggere quelle libertà.

Cosa è (e cosa non è) questo articolo

Questo articolo si concentra sulle idee di Stallman e sulle loro conseguenze pratiche: la definizione di Software Libero, il Progetto GNU, il copyleft e la GNU General Public License (GPL) — e su come questi hanno plasmato l'ecosistema open source moderno e le norme sulle licenze software.

Non è una biografia né un tuffo tecnico nella compilazione del kernel o nella gestione di repository. Non serve un background di programmazione per seguirlo.

Una visione equilibrata e accessibile

Stallman è influente e anche controverso. L'obiettivo qui è restare fattuali e leggibili: cosa ha sostenuto, quali meccanismi legali sono nati, come imprese e sviluppatori si sono adattati e dove continuano i dibattiti — così puoi capire perché il suo lavoro incide ancora sulle scelte software quotidiane.

Cosa significa davvero “software libero”

“Software libero” è facile da fraintendere perché la parola libero sembra indicare un prezzo. Richard Stallman usava libero per intendere libertà — la capacità degli utenti di controllare il software su cui contano.

Se un programma costa $0 ma non ti è permesso ispezionarlo, cambiarlo o condividerlo, può essere “gratis come la birra” ma comunque non libero nel senso che interessava a Stallman.

Le quattro libertà essenziali

Il software libero è definito da quattro permessi di base:

• Libertà 0: eseguire il programma per qualsiasi scopo.
• Libertà 1: studiare come funziona il programma e modificarlo per farlo funzionare come vuoi.
• Libertà 2: ridistribuire copie per aiutare gli altri.
• Libertà 3: distribuire le tue versioni modificate in modo che la comunità ne benefici.

Queste libertà riguardano l'autonomia: non sei solo un consumatore di strumenti — puoi diventare un partecipante che verifica, adatta e migliora.

Perché l'accesso al sorgente è non negoziabile

Le libertà 1 e 3 sono impossibili senza accesso al codice sorgente — le istruzioni leggibili dall'uomo. Senza di esso, il software è più simile a un elettrodomestico sigillato: puoi usarlo, ma non capire cosa fa, ripararlo quando si rompe o adattarlo a nuove esigenze.

L'accesso al sorgente è importante anche per la fiducia. Permette revisioni indipendenti (per privacy, sicurezza e correttezza) e rende possibile mantenere il software anche se lo sviluppatore originale smette di supportarlo.

Un'analogia semplice: ricette vs cibo sigillato

Pensa a un pasto al ristorante.

• Il software proprietario è come comprare un piatto pronto sigillato: puoi mangiarlo, ma non conosci gli ingredienti, non puoi modificare la ricetta e non puoi condividere copie.
• Il software libero è come avere la ricetta: puoi cucinarla a casa, imparare come è fatto, adattarla per allergie e condividere la tua versione migliorata con gli amici.

Questa è l'idea centrale: il software libero riguarda le libertà che gli utenti devono avere per restare padroni del loro computing.

Il problema a cui rispondeva Stallman

Prima che la “licenza software” diventasse un tema discusso, molte pratiche di programmazione — specialmente in università e laboratori di ricerca — si basavano su un'assunzione: se potevi migliorare uno strumento, condividevi il miglioramento. Il codice sorgente viaggiava con il software, le persone imparavano leggendo i lavori altrui e le correzioni si diffondevano tramite collaborazione informale.

Dalla cultura della condivisione al software bloccato

Quella cultura cambiò quando il software divenne un prodotto a sé. Aziende (e alcune istituzioni) cominciarono a considerare il codice sorgente un vantaggio competitivo. La distribuzione arrivò con termini di “vietata condivisione”, il codice non veniva più fornito con i programmi e gli accordi di riservatezza divennero comuni. Per sviluppatori abituati a risolvere problemi collettivamente, questo cambiamento non fu solo un fastidio: fu una modifica delle regole che rendeva rischioso risolvere problemi in comunità.

La storia della stampante (esempio, non mito)

Uno degli aneddoti più raccontati riguarda una stampante al MIT AI Lab. Stallman ha descritto come una nuova stampante arrivò con software distribuito solo in forma binaria, senza codice sorgente. Il problema pratico era banale: il laboratorio voleva modificare il programma per gestire notifiche di inceppamento o instradare i job in modo più intelligente. Secondo le vecchie norme “hacker”, qualcuno avrebbe patchato il codice e condiviso la correzione. Qui non si poteva — perché non era permesso vedere o cambiare il sorgente.

Vale la pena mettere le cose in proporzione: non è stata una stampante a creare il movimento globale. È stato un esempio chiaro e riconoscibile di una tendenza più ampia: strumenti su cui le persone dipendevano diventavano non riparabili dagli utenti.

Perché questo ha portato a nuove idee di licenza

Per Stallman, il nodo non era solo l'accesso tecnico: era la perdita della libertà di cooperare. Se non puoi studiare come funziona un programma, non puoi davvero controllarlo. Se non puoi condividere miglioramenti, le comunità si frammentano e tutti finiscono per reinventare correzioni in privato.

Quella motivazione ha modellato le innovazioni di licenza che sono seguite. Invece di affidarsi alla buona volontà o alle norme informali, Stallman voleva regole che preservassero la capacità di usare, studiare, modificare e condividere il software — così la collaborazione non potesse essere revocata nel momento in cui un programma diventava commercialmente prezioso.

Il Progetto GNU: costruire un OS libero

La mossa più grande di Stallman non fu solo scrivere un manifesto: fu avviare un progetto ingegneristico pratico. Nel 1983 annunciò il Progetto GNU, con un obiettivo ambizioso: costruire un sistema operativo completo che chiunque potesse usare, studiare, modificare e condividere, mantenendo la compatibilità con Unix così da poter eseguire programmi e workflow familiari.

Un sistema completo, non uno strumento singolo

Un sistema operativo non è un solo programma: è un intero stack. GNU si propose di creare tutti i pezzi necessari per rendere un computer utile quotidianamente, inclusi:

• Compilatori (in particolare GCC) per trasformare il codice in programmi eseguibili
• Utilità da linea di comando di base (copiare file, cercare testo, gestire processi)
• Librerie e strumenti per sviluppatori per sostenere la creazione di altro software
• Shell ed editor per lavorare effettivamente sulla macchina ogni giorno

In termini semplici: GNU costruiva l'impianto, non solo un singolo dispositivo.

GNU + Linux: come la maggior parte delle persone lo ha incontrato

All'inizio degli anni ’90, GNU aveva prodotto gran parte di questo “userland”, ma mancava un pezzo critico: il kernel (la parte che gestisce direttamente l'hardware e le risorse di sistema). Quando Linux apparve nel 1991, colmò quella lacuna.

Per questo molti sistemi popolari oggi combinano componenti GNU con il kernel Linux — spesso indicati come “GNU/Linux”.

L'infrastruttura contava quanto le idee

GNU rese l'idea del software libero concreta creando una base funzionante su cui altri potevano costruire. La filosofia spiegava perché la libertà importava; GNU fornì gli strumenti che rendevano la libertà pratica, ripetibile e scalabile.

Copyleft in parole semplici

Il copyleft è una strategia di licenza pensata per mantenere il software libero (in termini di libertà) non solo nella prima versione, ma anche nelle versioni future. Se ricevi codice copyleft, puoi usarlo, studiarlo, modificarlo e condividerlo — ma quando distribuisci la tua versione modificata devi trasferire le stesse libertà agli altri.

Uno strumento legale basato sul copyright

Il copyleft sembra “anti-copyright”, ma si basa proprio sul diritto d'autore. L'autore usa il suo copyright per imporre regole di permesso in una licenza: “Puoi copiare e modificare questo, ma se lo ridistribuisci devi mantenerlo sotto la stessa licenza.” Senza copyright non ci sarebbe un meccanismo legale per far rispettare queste condizioni.

L'idea del “condividi allo stesso modo” (con esempi semplici)

Pensalo come una regola che segue il codice:

• Fork: fai un fork di un progetto copyleft, aggiungi funzionalità e pubblichi il tuo fork. Devi pubblicare il codice sorgente e mantenere la stessa licenza così altri possono fare fork del tuo lavoro.
• Ridistibuzioni: includi il programma in un prodotto che spedisci ai clienti. Puoi chiedere soldi, ma devi fornire il sorgente e gli stessi diritti ai destinatari.

L'obiettivo è prevenire un modello che Stallman temeva: qualcuno prende il lavoro della comunità, lo migliora e poi nasconde quei miglioramenti.

Copyleft vs licenze permissive

Le licenze permissive (come MIT o BSD) generalmente ti permettono di fare quasi tutto col codice, compreso ridistribuire versioni modificate sotto una licenza proprietaria chiusa. Le licenze copyleft (come la GNU GPL) permettono comunque un ampio uso e modifica, ma richiedono che le opere derivate ridistribuite rimangano sotto gli stessi termini copyleft — così la libertà è preservata a valle.

Come la GNU GPL ha rimodellato le licenze

La GNU General Public License (GPL) ha cambiato il modo di fare licenze trasformando la “condivisione” in una regola applicabile, non solo in un gesto di cortesia. Prima della GPL, potevi ricevere il sorgente, migliorarlo e poi distribuire una versione chiusa che gli utenti non potevano studiare o modificare. La GPL ha girato quella dinamica: protegge le libertà degli utenti collegando condizioni alla ridistribuzione.

Cosa dà la GPL — e cosa chiede in cambio

A livello pratico, la GPL concede agli utenti il diritto di eseguire il programma per qualsiasi scopo, leggere e modificare il sorgente e condividere le versioni originali o modificate.

Se ridistribuisci software GPL (soprattutto in un prodotto), devi trasferire le stesse libertà. Questo di solito significa:

• Fornire il codice sorgente (o un modo valido per ottenerlo) ai destinatari
• Includere il testo della licenza e preservare le note di copyright
• Rilasciare le tue modifiche sotto GPL, così gli utenti a valle non vengono “bloccati”

Quando si applicano gli obblighi di distribuzione del sorgente

Le obbligazioni della GPL si attivano principalmente quando distribuisci il software ad altri — spedire binari, vendere dispositivi con il software, o consegnare copie ai clienti. Se modifichi codice GPL per uso interno e non lo distribuisci, in genere non sei obbligato a pubblicare il sorgente.

“Opera derivata” in termini pratici

Non serve la teoria legale per cogliere il succo: se il tuo programma incorpora codice GPL in modo da creare un'opera combinata (ad esempio collegandolo alla tua applicazione), il risultato è generalmente trattato come opera derivata e deve essere distribuito sotto GPL. Semplicemente eseguire un programma GPL, o comunicare con esso come processo separato tramite interfacce standard, spesso è diverso.

Varianti della GPL: v2, v3 e LGPL

GPLv2 è la versione classica e molto utilizzata. GPLv3 aggiunge protezioni su accordi di brevetto e sulla “tivoizzazione” (vendo hardware che blocca software modificato). La LGPL è pensata per librerie: permette il linking da programmi proprietari in certe condizioni mantenendo libera la libreria stessa.

Diritti — e responsabilità — degli sviluppatori con licenze libere

Le licenze libere (soprattutto la GNU GPL) non si limitano a “permettere” la condivisione — proteggono il diritto di studiare, modificare e ridistribuire il software in modo difficile da revocare. Per gli sviluppatori, questo significa che i tuoi miglioramenti possono restare disponibili per gli altri sotto le stesse condizioni, invece di essere assorbiti in un prodotto chiuso senza che la comunità ne tragga beneficio.

Quali diritti si acquisiscono

Con la GPL puoi:

• Smanettare con fiducia: leggere il sorgente, cambiarlo e eseguire la tua versione modificata.
• Condividere il tuo lavoro: distribuire copie del programma originale o modificato.
• Costruire sui miglioramenti altrui: perché i destinatari devono ottenere le stesse libertà.

Per questo la GPL è spesso descritta come “reciprocità applicabile”. Se qualcuno distribuisce un programma coperto da GPL (o un'opera derivata), non può aggiungere restrizioni che impediscano agli utenti a valle di modificare e condividere.

Quali responsabilità si assumono

Questi diritti comportano obblighi quando distribuisci software:

• Preservare avvisi di copyright e licenza.
• Fornire (o offrire) il sorgente corrispondente quando la GPL lo richiede.
• Mantenere la licenza intatta in modo che i destinatari conoscano i loro diritti.

Queste responsabilità non sono “trappole”: sono il meccanismo che impedisce che la collaborazione diventi estrazione unidirezionale.

Nota pratica sulla conformità

I team dovrebbero trattare la conformità delle licenze come l'igiene del rilascio. Tracciare:

• quali componenti open source distribuisci,
• le loro versioni e licenze,
• dove fornisci il sorgente (o offerte scritte),
• e le modifiche effettuate.

Un semplice Software Bill of Materials (SBOM) e una checklist ripetibile per i rilasci possono prevenire la maggior parte dei problemi molto prima che intervengano i legali.

Software libero vs Open Source: una divisione di valori

A livello di codice, “software libero” e “open source” spesso descrivono molti degli stessi progetti. La differenza riguarda soprattutto perché la condivisione è importante.

Priorità diverse: libertà vs adozione

Il movimento del Software Libero (associato a Richard Stallman e alla Free Software Foundation) considera la libertà del software una questione etica: gli utenti dovrebbero avere il diritto di eseguire, studiare, modificare e condividere il software. Non è solo migliore ingegneria: è la protezione dell'autonomia degli utenti.

L'approccio Open Source enfatizza risultati pratici: maggiore collaborazione, iterazioni più veloci, meno bug e miglior sicurezza grazie alla trasparenza. È comodo presentare l'apertura come un modello di sviluppo superiore senza dover assumere una posizione morale.

Perché “open source” ha preso piede

Nel 1998 l'Open Source Initiative (OSI) ha popolarizzato il termine “open source” per renderlo più appetibile alle aziende. “Software libero” veniva spesso frainteso come “senza costo” e alcune aziende diffidavano di un messaggio centrato su diritti ed etica. “Open source” ha dato alle organizzazioni un modo per dire “possiamo lavorare così” senza apparire ideologici.

Stesse licenze, inquadrature diverse

Molti progetti che si definiscono open source usano la GNU GPL o altre licenze copyleft, mentre altri scelgono licenze permissive come MIT o Apache. Il testo legale può essere lo stesso; cambia la storia raccontata ai contributori, agli utenti e ai clienti. Un messaggio è “questo protegge le tue libertà”, un altro è “questo riduce l'attrito e migliora la qualità”.

Una guida decisionale semplice

Se la priorità del tuo team è garantire che gli utenti a valle mantengano le stesse libertà, orientati verso il software libero e considera il copyleft.

Se la priorità è massimizzare l'adozione (incluso da aziende che potrebbero non volere obblighi reciproci), l'inquadratura open source — e spesso una licenza permissiva — può essere più adatta.

Se vuoi ampia collaborazione ma vuoi anche che i miglioramenti ricadano nella comunità, usa un linguaggio open source per approcciare il pubblico e scegli una licenza copyleft per il risultato.

Modelli di business e incentivi del mondo reale

Software libero non significa “nessuno viene pagato”. Significa che gli utenti hanno la libertà di eseguire, studiare, modificare e condividere il codice. Molte aziende costruiscono ricavi sani intorno a quella libertà — spesso offrendo servizi per problemi reali: affidabilità, responsabilità e tempo.

Come le aziende guadagnano con il FOSS

Alcuni modelli comprovati:

• Supporto e servizi: help desk a pagamento, SLA, formazione, audit, funzionalità personalizzate e migrazioni.
• Hosting e offerta gestita: vendere una versione ospitata dove i clienti pagano per comodità, scalabilità, backup e conformità.
• Doppia licenza: offrire lo stesso software sotto una licenza libera (spesso copyleft) e una licenza commerciale a pagamento per chi vuole termini diversi.
• Open core (con cautela): mantenere una base veramente libera e vendere componenti proprietari. Può funzionare, ma rischia di erodere la fiducia della community se la parte “libera” sembra limitata di proposito.

Una svolta moderna nel modello “offerta gestita” è l'ascesa di piattaforme che generano e avviano applicazioni rapidamente. Per esempio, Koder.ai è una piattaforma vibe-coding che aiuta i team a costruire app web, backend e mobile via chat — supportando al contempo l'esportazione del codice sorgente. Questa combinazione (iterazione rapida più proprietà del codice) si allinea ai valori della libertà del software: la possibilità di ispezionare, cambiare e spostare il tuo software quando necessario.

Perché permissivo vs copyleft influenza la strategia

La scelta di licenza può determinare chi cattura il valore:

• Licenze permissive (MIT/Apache) facilitano il riuso del tuo codice, anche da grandi vendor, aumentando l'adozione ma riducendo la possibilità di monetizzare l'esclusività.
• Licenze copyleft (GPL) richiedono ai ridistributori a valle di condividere le modifiche sotto gli stessi termini. Questo può scoraggiare fork chiusi e supportare modelli basati su servizi, distribuzioni certificate o doppia licenza.

“Commerciale” e “software libero” non sono opposti

“Commerciale” descrive come si vende; “software libero” descrive i diritti dell'utente. Un'azienda può vendere software libero, offrire supporto a pagamento e rispettare comunque la libertà del software.

Checklist di sostenibilità

Prima di adottare o basare un prodotto su un progetto FOSS, chiediti:

• C'è una community attiva (issue, release, review)?
• La governance è chiara (chi decide, come si risolvono i conflitti)?
• Il finanziamento è visibile (sponsor, backing aziendale, fondazione)?
• Il carico sui maintainer è sostenibile (bus factor, segnali di burnout)?
• Le pratiche di sicurezza sono documentate (cadenza patch, advisory)?

Malintesi comuni su GPL e FOSS

La GPL e il “FOSS” sono spesso discussi, ma alcuni miti ricorrenti confondono — specialmente per team che vogliono solo distribuire un prodotto senza violare licenze.

“GPL significa pubblico dominio”

Non è così. Il pubblico dominio significa che non c'è un titolare del copyright che impone condizioni — chiunque può riutilizzare l'opera senza obblighi.

La GNU GPL è l'opposto del “nessuna condizione”. L'autore mantiene il copyright e concede ampie autorizzazioni a usare, modificare e condividere — ma solo se rispetti i termini della GPL (in particolare condividere il sorgente quando distribuisci i binari coperti).

“Open source è sempre più sicuro”

Rendere il codice visibile può aiutare la sicurezza, ma non la garantisce. Un progetto open source può comunque essere:

• non mantenuto,
• poco revisionato,
• vulnerabile per anni prima che qualcuno se ne accorga.

La sicurezza viene da manutenzione attiva, audit, disclosure responsabile e buone pratiche operative — non dall'etichetta di licenza.

L'accusa della “licenza virale”

Si parla spesso della GPL come “virale” per suggerire che si diffonde incontrollata in tutto ciò che tocca. È una metafora carica.

Si riferisce in genere al copyleft: se distribuisci un'opera derivata del codice GPL, devi fornire il sorgente corrispondente sotto GPL. Quella clausola è deliberata: preserva le libertà degli utenti a valle. Non è un'infezione; è una condizione che puoi scegliere di accettare — o evitare usando codice con licenza diversa.

“Posso usare codice GPL nella mia app o servizio?” (regola generale)

Una regola pratica: gli obblighi scattano principalmente sulla distribuzione.

• Uso interno: usare software GPL dentro la tua azienda di solito non richiede pubblicare le modifiche.
• Spedire un'app/dispositivo: se distribuisci un programma con licenza GPL (o un derivato), di norma devi fornire sorgente e avvisi.
• SaaS / servizi web: eseguire software GPL su server generalmente non impone il rilascio del sorgente agli utenti. (L'AGPL è stata creata per chiudere questo gap.)

Quando è rilevante, ottieni una lettura precisa basata su come il codice è combinato e distribuito — non affidarti a soli assunti.

Critiche, controversie e dibattiti in corso

Richard Stallman è una figura controversa. Si può riconoscerlo e allo stesso tempo parlare chiaramente dell'influenza duratura delle idee e delle licenze a lui associate.

Un punto utile è separare due conversazioni: (1) i dibattiti su Stallman come persona e membro della community; (2) l'impatto misurabile dei principi del software libero, del Progetto GNU e della GNU GPL sulle licenze software e sui diritti degli sviluppatori. Il secondo può essere discusso con fonti primarie (testi di licenza, storie di progetto, pattern di adozione) anche quando le opinioni sulla prima sono forti.

Governance e “chi decide?”

Una critica ricorrente non riguarda le licenze ma la governance: come i progetti prendono decisioni, chi ha autorità e cosa succede quando fondatori, maintainer e utenti vogliono cose diverse. Le comunità del software libero si sono confrontate con domande come:

• Come si sceglie o si sostituisce la leadership?
• Le fondazioni dovrebbero essere guidate dai membri, dal board o dai maintainer?
• Quando la “libertà” per i maintainer confligge con le esigenze dei contributori?

Queste questioni contano perché le licenze stabiliscono termini legali, ma non creano automaticamente processi decisionali sani.

Inclusività, condotta e standard di comunità

Un altro dibattito riguarda inclusività e norme comunitarie: come i progetti definiscono comportamenti rispettosi, come gestiscono conflitti e quanto siano accoglienti per i nuovi arrivati. Alcune community adottano codici di condotta formali; altre preferiscono regole minime e moderazione informale. Nessun approccio è automaticamente “giusto”, ma i compromessi sono reali e vanno discussi senza attacchi personali.

Tenere la discussione ancorata ai fatti

Se valuti l'eredità di Stallman, aiuta mantenere le affermazioni verificabili: cosa richiede la GPL, come il copyleft ha cambiato le pratiche di conformità e come queste idee hanno influenzato licenze e istituzioni successive. Puoi essere critico, favorevole o indeciso — mira sempre a precisione, rispetto e chiarezza su ciò che si sta criticando.

Conclusioni pratiche: scegliere licenze e contribuire

Il dono pratico più grande di Stallman per i team di tutti i giorni è una domanda chiara: quali libertà vuoi garantire a valle? Rispondere a questa domanda trasforma la “scelta della licenza” da sensazione in decisione.

Un albero decisionale semplice

• Vuoi che altri (inclusi i concorrenti) riutilizzino il tuo codice con condizioni minime? Scegli una licenza permissiva (es. MIT, Apache-2.0).
• Vuoi che i miglioramenti al tuo codice restino condivisibili quando vengono ridistribuiti? Scegli copyleft forte (es. GNU GPL).
• Vuoi che la condivisione si applichi principalmente alle modifiche della tua libreria, permettendo alle app proprietarie di linkare? Scegli copyleft debole (es. LGPL, MPL).

Se sei indeciso, decidi in base all'obiettivo: adozione (permissiva) vs reciprocità (copyleft) vs reciprocità compatibile con librerie (copyleft debole).

Passi pratici per spedire software responsabilmente

1. Scegli una licenza per progetto e dichiarala chiaramente nel README.
2. Aggiungi un file LICENSE nella radice del repo (copia il testo completo della licenza).
3. Aggiungi header di copyright dove la tua organizzazione li richiede.
4. Documenta le dipendenze (dirette e transitive rilevanti) e le loro licenze.
5. Se distribuisci binari, prepara gli avvisi necessari, le offerte di sorgente (se applicabili) e le attribuzioni.

Se costruisci prodotti usando sviluppo assistito dall'AI (inclusi strumenti chat come Koder.ai), questa checklist è ancora più importante: stai comunque distribuendo dipendenze reali, artefatti reali e obblighi di licenza reali. La velocità non rimuove la responsabilità — la rende solo più utile una routine di conformità ripetibile.

Crea una routine di conformità interna leggera

Rendila noiosa e ripetibile:

• Genera un SBOM durante le build.
• Mantieni un template per il file notices e aggiornalo quando cambiano le dipendenze.
• Aggiungi un checkpoint di revisione licenze alle PR/rilasci (anche solo una checklist di 10 minuti).

Per confronti più approfonditi, vedi /blog/choosing-an-open-source-license e /blog/gpl-vs-mit-vs-apache.