So forks with modules added or removed cannot be called Python? Forks without the blessing of the PSF cannot be called Python? That's really not open source.
- https://cloud.google.com/appengine/docs/python/python25/diff27 - "PEP: Distributing a Subset of the Standard Library" https:// groups.google.com/forum/m/#!topic/python-ideas/DP5OeJu94eI - https://www.python.org/dev/peps/pep-0534/ https://www.python.org/psf/trademarks/ I think trying to maintain a fork without support from the community is a bad idea for a number of reasons: - How quickly are vulnerability fixes to be backported? (if ever) - Duplication of effort - Fragmentation But as an academic exercise, what a useful way to review both Python 2 and 3. But it's very common for folks to apply patches and still call the package and the binary 'python' (with the same version number): - https://github.com/ContinuumIO/anaconda-recipes/tree/master/python-2.7 *.patch - https://apps.fedoraproject.org/packages/python-devel/sources/ - http://packages.ubuntu.com/source/xenial/python-defaults - Distribution XYZ redistribution [Python 2.7.12] - Unmerged development forks With these license and trademark policies, does unblessed fork need to: - change their project name to not include the word "python" - change the binary name so that simple PATH changes don't work - clutter their diffs with noise - use an arbitrary version number Where is that stated? Are all unmerged development forks / branches in violation of said policy? The fork in immediate question is not backwards-compatible with Python 2. It's clear that the PSF position is that there will never be an official Python 2.8; and that development time and effort are better spent porting things to the backwards-incompatible Python 3.4/3.6. On Saturday, December 10, 2016, David Mertz <me...@gnosis.cx> wrote: > > > On Dec 10, 2016 10:42 AM, "Wes Turner" <wes.tur...@gmail.com > <javascript:_e(%7B%7D,'cvml','wes.tur...@gmail.com');>> wrote: > > and this is on purpose, since Python is BSD software which >> anyone can use, modify, fork, etc. >> > > So, otherwise everyone who forks for any reason is in violation of the > trademark policy? > > > The trademark issue has nothing to do with the code copyright or forking. > PyPy, Brython, IronPython, Jython are all distinct code bases that > implement (mostly) the same language semantics. Probably all of those use > some code from CPython, but even if some other implementation used zero > common code it wouldn't matter. > > None of those projects are allowed to call their next release "Python 2.8" > either, regardless of precise semantics implemented. I could call some > project Foothon 2.8 if I wanted, because it wouldn't invite confusion about > official status for the PDF. >
_______________________________________________ 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
