On 11 December 2016 at 13:23, Wes Turner <wes.tur...@gmail.com> wrote: > On Saturday, December 10, 2016, Terry Reedy <tjre...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
