Showing content from http://mail.python.org/pipermail/python-dev/attachments/20161210/d2e5d623/attachment.html below:
<div><br></div><div>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.</div><div><br></div><div>-Â <a href="https://cloud.google.com/appengine/docs/python/python25/diff27">https://cloud.google.com/appengine/docs/python/python25/diff27</a></div><div>- "<span style="background-color:rgb(235,239,249);font-family:Arial,Helvetica,sans-serif;font-weight:bold">PEP: Distributing a Subset of the Standard Library" https</span>://<a href="http://groups.google.com/forum/m/#!topic/python-ideas/DP5OeJu94eI">groups.google.com/forum/m/#!topic/python-ideas/DP5OeJu94eI</a></div><div>Â -Â <a href="https://www.python.org/dev/peps/pep-0534/">https://www.python.org/dev/peps/pep-0534/</a></div><br><a href="https://www.python.org/psf/trademarks/">https://www.python.org/psf/trademarks/</a><div><br></div><div>I think trying to maintain a fork without support from the community is a bad idea for a number of reasons:</div><div><br></div><div>- How quickly are vulnerability fixes to be backported? (if ever)</div><div>- Duplication of effort</div><div>- Fragmentation</div><div><br></div><div>But as an academic exercise, what a useful way to review both Python 2 and 3.</div><div><br></div><div>But it's very common for folks to apply patches and still call the package and the binary 'python' (with the same version number):</div><div><br></div><div>-Â <a href="https://github.com/ContinuumIO/anaconda-recipes/tree/master/python-2.7">https://github.com/ContinuumIO/anaconda-recipes/tree/master/python-2.7</a> *.patch</div><div>-Â <a href="https://apps.fedoraproject.org/packages/python-devel/sources/">https://apps.fedoraproject.org/packages/python-devel/sources/</a></div><div>-Â <a href="http://packages.ubuntu.com/source/xenial/python-defaults">http://packages.ubuntu.com/source/xenial/python-defaults</a></div><div>- Distribution XYZ redistribution [Python 2.7.12]</div><div>- Unmerged development forks</div><div><br></div><div>With these license and trademark policies, does unblessed fork need to:</div><div><br></div><div>- change their project name to not include the word "python"</div><div>- change the binary name so that simple PATH changes don't work</div><div>- clutter their diffs with noise</div><div>- use an arbitrary version number</div><div><br></div><div>Where is that stated?</div><div><br></div><div>Are all unmerged development forks / branches in violation of said policy?</div><div><br></div><div>The fork in immediate question is not backwards-compatible with Python 2.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br>On Saturday, December 10, 2016, David Mertz <<a href="mailto:mertz@gnosis.cx">mertz@gnosis.cx</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Dec 10, 2016 10:42 AM, "Wes Turner" <<a href="javascript:_e(%7B%7D,'cvml','wes.turner@gmail.com');" target="_blank">wes.turner@gmail.com</a>> wrote:<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and this is on purpose, since Python is BSD software which<br>
anyone can use, modify, fork, etc.<br></blockquote><div><br></div></div><div>So, otherwise everyone who forks for any reason is in violation of the trademark policy?</div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div class="gmail_extra" dir="auto"></div></div>
</blockquote></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4