Tra il giugno 2000 e l’aprile 2001 Python è uscito sotto almeno tre testi di licenza diversi, ciascuno legato a un titolare diverso dei diritti. È questo il problema che la nascita del Python Software Foundation (PSF), annunciata il 6 marzo 2001, prova a risolvere. Il rilascio di Python 2.1, il 17 aprile 2001, è un buon momento per tornare su quel groviglio di licenze, perché racconta qualcosa che il changelog tecnico non dice.

Contesto

Python nasce al CWI di Amsterdam alla fine degli anni ottanta, scritto da Guido van Rossum. Dal 1995 lo sviluppo continua alla Corporation for National Research Initiatives (CNRI), a Reston, in Virginia. Nel maggio 2000 van Rossum e il gruppo di sviluppo passano a BeOpen.com e fondano il team PythonLabs; nell’ottobre dello stesso anno il team si sposta di nuovo, a Digital Creations, l’azienda dietro l’application server Zope.

Ogni trasloco ha lasciato un segno nei file di licenza. Python 1.6 e 2.0, entrambi del 2000, escono sotto un testo redatto da CNRI. La 2.0.1 e poi la 2.1 portano in calce una catena stratificata di avvisi di copyright: CNRI per il nucleo storico, BeOpen per le modifiche del 2000, e infine il PSF appena nato. Apri il file LICENSE di Python 2.1 e trovi una sequenza di accordi sovrapposti, uno per ogni trasloco.

Il problema

La licenza CNRI usata per Python 1.6 conteneva una clausola di scelta della legge applicabile (choice-of-law), che la ancorava alla giurisdizione della Virginia. Richard Stallman ha sostenuto pubblicamente che quella clausola rende la licenza incompatibile con la GNU General Public License (GPL): la GPL non ammette restrizioni oltre a quelle che impone lei stessa, e una clausola di foro è una di queste. La conseguenza pratica è netta. Un programma rilasciato sotto GPL non può incorporare né linkare, in modo lecito, codice coperto da una licenza con quella clausola.

La risposta arriva con Python 1.6.1, pubblicato nel 2001: il testo viene ritoccato per togliere o aggirare l’ostacolo. Secondo CNRI, l’avvocato di Stallman avrebbe detto che la 1.6.1 è “non incompatibile” con la GPL — una formula prudente, che dice da sola quanto la questione fosse delicata sul piano legale prima ancora che su quello tecnico. Qui la distinzione tra “open source” e “compatibile con la GPL” si fa concreta: ogni versione di Python è open source secondo i criteri della Open Source Initiative, ma non tutte sono state compatibili con la GPL.

Punto critico

Non è una questione di qualità del codice. È che i diritti erano sparsi tra soggetti che non coincidevano con la comunità di sviluppo. CNRI deteneva i diritti sul nucleo storico, BeOpen su un blocco di contributi, e nessuno dei due aveva come scopo statutario la custodia di lungo periodo del linguaggio. È bastata una clausola di foro, inserita per ragioni interne a un singolo ente, a generare un’incompatibilità che ricade su chiunque distribuisca software derivato.

Il PSF è la risposta strutturale. È un’organizzazione senza scopo di lucro nata per detenere i diritti relativi a Python: il marchio, il copyright sul codice della distribuzione di riferimento, e il compito di tenere una sola licenza coerente per i rilasci futuri. Spostare i diritti da un’azienda — il cui ciclo di vita, le cui priorità commerciali e le cui clausole legali rispondono ad altri interessi — a una fondazione dedicata cambia la garanzia che l’utente riceve. La licenza smette di essere un sottoprodotto della storia societaria di chi paga gli sviluppatori.

Implicazioni

Chi deve scegliere su cosa costruire può verificare la lezione aprendo i file. La salute di un progetto open source non si misura solo sul ritmo dei rilasci o sulla ricchezza della libreria standard — in Python, i moduli per socket, HTTP, parsing XML ed espressioni regolari che viaggiano con l’interprete. Si misura anche su chi detiene i diritti e su quale testo di licenza si applica davvero al codice che stai per linkare.

Le novità tecniche di Python 2.1 — lo scoping lessicale annidato di PEP 227, che si attiva con from __future__ import nested_scopes e diventerà il comportamento predefinito nella 2.2, e le weak reference di PEP 205 — arrivano attraverso il processo pubblico delle Python Enhancement Proposals (PEP). PEP 227, scritta da Jeremy Hylton e datata 1 novembre 2000, viene discussa e revisionata allo scoperto prima di entrare nel linguaggio. Lo stesso principio di trasparenza che governa l’evoluzione tecnica vale per i diritti solo se esiste un soggetto stabile a custodirli. Il PSF è quel soggetto.

Limiti

La nascita del PSF, a marzo 2001, non chiude subito ogni questione. La catena di copyright nei rilasci 2.0.x e 2.1 resta stratificata, perché riconoscere come si deve i contributi storici di CNRI e BeOpen è un obbligo, non un’opzione: i loro avvisi restano nel file LICENSE anche dopo che la fondazione ha preso in mano il governo dei rilasci. La piena unificazione su un testo di licenza pulito e stabile sotto il PSF è un percorso ancora aperto, non un fatto chiuso mentre scrivo. La compatibilità con la GPL, per le versioni con la clausola di foro, dipende ancora da interpretazioni legali su cui le parti non hanno preso una posizione del tutto univoca.

Quello che il caso mostra è circoscritto e solido: un linguaggio tecnicamente maturo può trascinarsi per più di un anno un problema di licenza nato non dal codice, ma da chi ne detiene i diritti. La correzione passa dalla governance, prima ancora che dal compilatore.

Immagine di copertina: Logo storico “dot matrix” di Python: la parola “python” in caratteri stilizzati, usata sul sito ufficiale fino al 2006 — logo di Just van Rossum, pubblico dominio — https://commons.wikimedia.org/wiki/File:Python_logo_1990s.svg