Between June 2000 and April 2001 Python shipped under at least three different licence texts, each tied to a different rights holder. That is the problem the Python Software Foundation (PSF), announced on 6 March 2001, sets out to solve. The release of Python 2.1, on 17 April 2001, is a good moment to go back to that licensing tangle, because it tells you something the technical changelog does not.

Context

Python was born at CWI in Amsterdam in the late 1980s, written by Guido van Rossum. From 1995 development continued at the Corporation for National Research Initiatives (CNRI), in Reston, Virginia. In May 2000 van Rossum and the development group moved to BeOpen.com and founded the PythonLabs team; in October of the same year the team moved again, to Digital Creations, the company behind the Zope application server.

Each move left a mark in the licence files. Python 1.6 and 2.0, both from 2000, came out under a text drafted by CNRI. The 2.0.1 and then the 2.1 carry a layered chain of copyright notices: CNRI for the historical core, BeOpen for the 2000 changes, and finally the newly born PSF. Open the LICENSE file of Python 2.1 and you find a sequence of overlapping agreements, one for each move.

The problem

The CNRI licence used for Python 1.6 contained a choice-of-law clause anchoring it to the jurisdiction of Virginia. Richard Stallman argued publicly that this clause makes the licence incompatible with the GNU General Public License (GPL): the GPL admits no restrictions beyond those it imposes itself, and a venue clause is one of them. The practical consequence is sharp. A program released under the GPL cannot lawfully incorporate or link code covered by a licence carrying that clause.

The answer came with Python 1.6.1, published in 2001: the text was adjusted to remove or sidestep the obstacle. According to CNRI, Stallman’s lawyer is reported to have said that 1.6.1 is “not incompatible” with the GPL — a cautious wording that tells you on its own how delicate the matter was in legal terms before it was so in technical ones. Here the distinction between “open source” and “GPL-compatible” turns concrete: every Python release is open source by the criteria of the Open Source Initiative, yet not all of them have been GPL-compatible.

The critical point

This is not a question of code quality. It is that the rights were spread across parties that did not coincide with the development community. CNRI held the rights to the historical core, BeOpen to a block of contributions, and neither had the long-term stewardship of the language as its chartered purpose. A single venue clause, inserted for reasons internal to one body, was enough to generate an incompatibility that falls on anyone distributing derived software.

The PSF is the structural answer. It is a non-profit organisation born to hold the rights relating to Python: the trademark, the copyright on the reference distribution’s code, and the task of keeping a single coherent licence for future releases. Moving the rights from a company — whose life cycle, commercial priorities and legal clauses answer to other interests — to a dedicated foundation changes the guarantee the user receives. The licence stops being a by-product of the corporate history of whoever pays the developers.

Implications

Anyone choosing what to build on can check the lesson by opening the files. The health of an open source project is not measured only by the cadence of releases or the richness of the standard library — in Python, the modules for sockets, HTTP, XML parsing and regular expressions that travel with the interpreter. It is also measured by who holds the rights and by which licence text actually applies to the code you are about to link against.

Python 2.1’s technical additions — the nested lexical scoping of PEP 227, switched on with from __future__ import nested_scopes and due to become the default behaviour in 2.2, and the weak references of PEP 205 — arrive through the public process of the Python Enhancement Proposals (PEP). PEP 227, written by Jeremy Hylton and dated 1 November 2000, is discussed and reviewed in the open before it enters the language. The same transparency principle that governs technical evolution holds for the rights only if a stable body exists to steward them. The PSF is that body.

Limits

The founding of the PSF, in March 2001, does not close every question at once. The copyright chain in the 2.0.x and 2.1 releases stays layered, because acknowledging the historical contributions of CNRI and BeOpen properly is an obligation, not an option: their notices stay in the LICENSE file even after the foundation takes the governance of releases in hand. Full unification onto a clean, stable licence text under the PSF is a path still open, not a settled fact as I write. GPL compatibility, for the versions with the venue clause, still depends on legal interpretations on which the parties have not taken a wholly unambiguous position.

What the case shows is narrow and solid: a technically mature language can drag a licensing problem along for more than a year — a problem born not of the code but of whoever holds the rights to it. The fix runs through governance before it runs through the compiler.

Cover image: Historic Python “dot matrix” wordmark logo: the word “python” in stylized lettering, used on the official site until 2006 — logo by Just van Rossum, public domain — https://commons.wikimedia.org/wiki/File:Python_logo_1990s.svg