Python 2.8?

By Jake Edge
January 11, 2017

The appearance of a "Python 2.8" got the attention of the Python core developers in early December. It is based on Python 2.7, with features backported from Python 3.x. In general, there was little support for the effort—core developers tend to clearly see Python 3 as the way forward—but no opposition to it either. The Python license makes it clear that these kinds of efforts are legal and even encouraged—any real opposition to the project lies in its name.

Larry Hastings alerted the python-dev mailing list about the Python 2.8 project (which has since been renamed to "Placeholder" until another name can be found). It is a fork of Python 2.7.12 with features like function annotations, yield from,async/await, and the matrix multiplication operator ported from Python 3. It is meant to be a drop-in replacement for Python 2.7, so it won't have features that are incompatible with it. It is aimed at those who are not ready (or willing) to make the jump to Python 3, but want some of the features from it.

The name "Python 2.8" implies a level of support, though; it also uses a name (Python) that is trademarked by the Python Software Foundation. Steven D'Aprano recalled discussions at the time of the decision to stop Python 2.x development at 2.7:

I seem to recall that when we discussed the future of Python 2.x, and the decision that 2.7 would be the final version and there would be no 2.8, we reached a consensus that if anyone did backport Python 3 features to a Python 2 fork, they should not call it Python 2.8 as that could mislead people into thinking it was officially supported.

He and others called for the project to be renamed. An issue was filed for the project suggesting a rename. As it turns out, the owner of the project, Naftali Harris, is amenable to the change, which simplifies things greatly. Had that not been the case, though, it is not entirely clear that the PSF Trademark Usage Policy precludes using the name "Python" that way.

David Mertz, who is a member of the PSF Trademarks committee, believes that "Python 2.8" would be a misuse of the trademark and referred it to the committee. Terry Reedy agreed, saying that the project was a "derived work" and that clause 7 of the Python License does not automatically allow the use of the PSF trademarks.

But Marc-Andre Lemburg noted that the trademark policy is seemingly written to allow for uses like this. The policy says:

[...] stating accurately that software is written in the Python programming language, that it is compatible with the Python programming language, or that it contains the Python programming language, is always allowed. In those cases, you may use the word "Python" or the unaltered logos to indicate this, without our prior approval.

He pointed out that the project also fulfilled the license requirements by listing the differences from 2.7.12 as is required in clause 3. But he agreed that a name change should be requested. For his part, Guido van Rossum is not particularly concerned by the existence of the project:

While I think the name is misleading and in violation of PSF policy and/or license, I am not too worried about this. I expect it will be tough to port libraries from Python 3 reliably because it is not true Python 3 (e.g. str/bytes). So then it's just a toy. Who cares about having 'async def' if there's no backport of asyncio?

Mertz, however is not so sure. The existence of a "Python 2.8" may "serve as a pretext for managers to drag their feet further on migration plans", which will be detrimental to organizations where that happens. PEP 404 (the "Python 2.8 Un-release Schedule") makes it quite clear that the core development team (and, presumably, the PSF) is resolute about a 2.8 release: "There never will be an official Python 2.8 release. It is an ex-release."

But there are various other projects that have "Python" in their names (IronPython, ActivePython, MicroPython, etc.) as well as projects with names that are suggestive of Python without directly using the name (Jython, PyPy, Cython, Mython, and so on). Where is the line to be drawn? As with all trademark questions, though, it comes down to a question of user confusion: will users expect that something called "Python 2.8" is officially endorsed and supported by the PSF? The answer would seem to clearly be "yes".

Luckily, everyone is being fairly reasonable—no legal action has been needed or even really considered. The fact that Harris was willing to change the name obviated any need to resort to legal remedies. The GitHub issue thread is full of suggestions for alternate names, replete with Monty Python references—our communities love to bikeshed about names. There are also some snide comments about Python 3 and the like, but overall the thread was constructive.

As far as new names go, an early favorite was "Pythonesque", but calling the binary "pesque" reminded some of the word "pesky", which is not quite what Harris is after (though "pyesque" might work). Herenamed the project to "Placeholder" on December 12 "while we find a good permanent name that I like and that works for the PSF". The current leader appears to be Pyvergent (since Mython already exists and one might guess that Harris is not entirely serious about Placeholder). In any case, he said, the decision does not need to be made immediately.

At this point, Placeholder appears to largely be a one-developer project. Its GitHub history starts in October 2016 and some real progress has seemingly been made; quite a few features have been ported from Python 3. The issues list shows some ambitious plans that might make it less of a "toy" than Van Rossum envisioned. If it ends up being popular and attracting more of a community, it could perhaps become a strong player in the Python world.

There is a balance to be struck on trademark policies for free-software projects. As we saw in the Debian-Mozilla trademark conflict, which resulted in the "Iceweasel" browser and was resolved early last year, distributions and others want to be able to make changes to projects while still being able to use the trademarks. As Nick Coghlan pointed out, for Python, Linux distributions are likely pushing the envelope the furthest:

Linux distros probably diverge the furthest out of anyone distributing binaries that are still recognised as a third party build of CPython, such that the Linux system Python releases are more properly called "<distro> Python" rather than just Python. However, distro packaging formats are also generally designed to clearly distinguish between the unmodified upstream source code and any distro-specific patches, so the likelihood of confusion is low (in a legal sense).

It would seem that the PSF might want to tighten its policy slightly such that it retains control over "Python x.y" and similar trademarks, while still allowing the Python name to appear in the names of other related projects (like MicroPython). That way, if legal action is actually needed at some point (which no one wants to see, of course) it will be clear that the intent and the policy line up. Fragmentation is a clear possibility given the "forkable" nature of free-software projects, but it is certainly not unreasonable for the parent project to retain a measure of control to reduce confusion—that is precisely what trademarks are for.