[Python-Dev] Someons's put a "Python 2.8" on GitHub

[Nick Coghlan]

On 11 December 2016 at 13:23, Wes Turner <wes.turner at gmail.com> wrote:
> On Saturday, December 10, 2016, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 12/10/2016 5:28 PM, Wes Turner wrote:
>>> So forks with modules added or removed cannot be called Python?
>>
>> Distributions that make parts of the stdlib optional are not forks.  The
>> PSF Windows installer makes tcl/tk, tkinter, IDLE, and turtle? modules
>> optional.
>>
>> Distributions that package additional modules with unmodified python x.y
>> are also, to me, not forks.  But they are always given other names for the
>> combined package.  ActiveState Python, Enthought Python, Anaconda (Python).
>> Separate names for separate distribution allow people to search for
>> particular distributions and discuss questions like "Which distribution is
>> best for purpose A?"
>>
>> I am sure that ActiveState Software Inc. would not be happy if you
>> distributed Python + selected modules and called it 'ActiveState Python'
>> ;-),  Some for other distributions.
>
> So there needs to be a prefix or a suffix?
>
>   [prefix] Python
>   Python [suffix]

There needs to be an avoidance of confusion, such that folks are aware
of what's being published directly under the PSF's authority (by way
of python-dev's selected release managers), and what's being modified
by other people.

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).

As Terry notes, other redistributors are similar (just with fewer
patches in most cases) - providing pre-built, potentially patched,
binaries is standard practice, but the end result is branded as
something *other* than an unqualified "Python" release.

Alternative *implementations* that embed the word mark in their name,
like MicroPython and IronPython, can diverge even further, and will
often mix and match the specifics of which versions they support (e.g.
if their base version is 3.X, and a neat feature comes out in 3.X+2,
they're free to add that if they want to do so, even if there are
still other features from 3.X+1 that they're still working on).

The simplest option from a legal perspective is for folks to use a
clearly distinct name (e.g. PyPy, Jython, Cython, Pyjion, Numba, VOC,
Batavia, Mython), as then the question of appropriate use of the
"Python" word mark doesn't even come up - it only gets used in a
nominative sense (i.e. "this is a Python implementation" or "this is a
Python superset"), which is always OK.

In this particular case, there just happened to be an obvious name for
the project (courtesy of PEP 404) that was nevertheless problematic on
the "potential for confusion" trademark front. Fortunately, there have
been a few interesting alternative name suggestions on the GitHub
issue, so once Naftali picks one that the PSF agrees is fine, the
issue will be resolved.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia