5 ms·

The biggest problem is having a place to organise. The Python foundation is threatening to sue anyone continuing something called Python 2, or even a similar n

The biggest problem is having a place to organise. The Python foundation is threatening to sue anyone continuing something called Python 2, or even a similar name. Finding volunteers who are willing to get sued to work on Python will be hard.

VBprogrammer 7y ago
The motivation for that is probably avoiding what my first thought was; who is going to be the first to offer commercial extension of Python 2 support. That would be worth a lot of money to a lot of companies.
- robocat 7y ago
  Also I can think of plenty of groups that would like to be able to deploy a differently secured version 2 in their best financial interest.
CogitoCogito 7y ago
I think you're blowing it out of proportion. Call your project some other name. Say that your interpreter is compatible with Python 2 and that you provide continued support. It will probably be hard to find volunteers because most are moving/have moved to Python 3, but I don't think the threat of lawsuit will scare anyone away except those who want to infringe on PSF's trademarks and in that case...good?
- bigiain 7y ago
  I'm finding it difficult to understand why anybody thinks supporting Python2 should be done by volunteers? What's "in it" for the volunteer? How much "fun" does "Supporting an old language where the original developers have moved on to a newer and more interesting version of the language, but there's a bunch of complaining people who still want the old language to be supported but they aren't offering to pay for it" sound? I'd rather sit in the park reading a book or walk a dog or something. I mean, there's still people taking on COBOL contracts, because businesses consider their COBOL code to be important enough to keep maintained. But they sure as hell aren't "volunteering". They're getting paid rates that even bay area twenty-something FAANG-ers would be impressed by. If Blackrock or The Vanguard Group or equivalent decided they needed continued Python2 support because it was a critical dependency on their ETF platforms (and they'd been foolish enough to not heed the "Goddamn it, just fucking upgrade to Python3 already!" advice from the core team for about a decade), I'm sure they could whip out their chequebooks and agree to a rate that Guido himself would agree support Python2 for them. But I'd hope and expect Guido (or whoever in the core team would be suitable candidates to do this work) to hold out for genuinely life-changing numbers of zeros on those cheques. And if nobody is offering to write those cheques? Well maybe that says something about the seriousness of their complaints?
  - CogitoCogito 7y ago
    > I'm finding it difficult to understand why anybody thinks supporting Python2 should be done by volunteers? I 100% agree. I was just responding to the parent post.
wongarsu 7y ago
Continuing a fork under the original name would be confusing to everyone and bad manners, aside from infringing the trademark. But nobody is stopping people from organising around a fork called "Omphalos - a Python 2 fork" or whatever
- toyg 7y ago
  Somebody has done just that already, it’s easily googleable. Nobody really cares though - why would you purposefully tie yourself to an objectively-inferior featureset, full of problems that have already been solved in py3? Because you can’t bear the use of parentheses for print, really?
  - jsjohnst 7y ago
    > Because you can’t bear the use of parentheses for print, really? While I generally share your POV, it doesn’t do justice to the situation to trivialize the upgrade like that. Anyone with C based dependencies will have a rougher time (but not that “rough”) due to ABI changes. The harder userland change is string handling anyway (which isn’t that hard either), not parens on print.
    - toyg 7y ago
      You are right. I'm probably still shellshocked by the initial wave of complaints, so many years ago...
    - Drdrdrq 7y ago
      ...and those parenthesis are annoying as hell. :)
- zajio1am 7y ago
  It would not be fork when the original project (Python 2) is no longer developed. There are many cases of cooperative maintainership handover without name change and nobody cares. I understand using trademark as an advantage in cases of a hostile fork, but if the original maintainer no longer plan to do any bugfixing then it seems like a dick move.
avian 7y ago
Are you referring to that "Python 2.8" thing [1] that happened some years ago? A comment from PSF [2] makes it clear that they don't have any issue with people continuing to develop their Python 2 codebase further. It is what their open source explicitly permits after all. They do have issue with people using a trademarked name and not making it clear that their work isn't endorsed by the Python Foundation. [1] https://www.naftaliharris.com/blog/why-making-python-2.8/ https://www.naftaliharris.com/blog/why-making-python-2.8/ [2] https://news.ycombinator.com/item?id=13147972 https://news.ycombinator.com/item?id=13147972
- CJefferson 7y ago
  For me, if I want most existing python2 programs to work, I'd want to release my program as called "python", so "#!/usr/bin/env python" continued to work. If I'm not allowed to do that, then you are already adding a lot of friction to continuing to support existing python installs. Although, I wonder if you could claim you need to call it that for the programs to work?
XCabbage 7y ago
You've asserted this twice on this post, both times without any evidence. I Googled, couldn't find the threat you're basing the claim on, but DID find that the PSF Trademark Usage Policy (https://www.python.org/psf/trademarks/ https://www.python.org/psf/trademarks/) explicitly allows most sorts of freely distributed Python-related products to use the name without permission: > Use of the word "Python" in the names of freely distributed products like IronPython, wxPython, Python Extensions, etc. -- Allowed when referring to use with or suitability for the Python programming language. We can quibble about whether a Python 2 fork would technically meet the definition here, but it seems to me that it would meet it at least as much as IronPython does; going after such a fork would contradict the rule implied by the examples in this section, even if it doesn't unambiguously violate the definition. I think they've already granted the public the right to use the word "Python" in a Python 2 fork and couldn't successfully sue over it now even if they wanted to. What's your basis for suggesting that they've threatened to do so?
- CJefferson 7y ago
  Sorry, I shouldn't assume people know the same things I know. I know this has come up at least three times I've seen, but I'm having trouble finding them all. Here's one: https://github.com/naftaliharris/tauthon/issues/47 https://github.com/naftaliharris/tauthon/issues/47 In this case there was plans to call something py28, to which Guido replied "OK, bring in the lawyers".
  - ZWoz 7y ago
    CJefferson probably refers that GvR comment (Though I don't see that strong language here): """ Since I was asked: The project's name (and its binary name) need to change. They are misleading. The rest looks acceptable according to Python's license. This is not an endorsement (far from it). """
    - CJefferson 7y ago
      Expand all comments. One is exactly what I quote.
  - 7y ago

VBprogrammer 7y ago

The motivation for that is probably avoiding what my first thought was; who is going to be the first to offer commercial extension of Python 2 support. That would be worth a lot of money to a lot of companies.

robocat 7y ago
Also I can think of plenty of groups that would like to be able to deploy a differently secured version 2 in their best financial interest.

CogitoCogito 7y ago

I think you're blowing it out of proportion. Call your project some other name. Say that your interpreter is compatible with Python 2 and that you provide continued support. It will probably be hard to find volunteers because most are moving/have moved to Python 3, but I don't think the threat of lawsuit will scare anyone away except those who want to infringe on PSF's trademarks and in that case...good?

bigiain 7y ago
I'm finding it difficult to understand why anybody thinks supporting Python2 should be done by volunteers? What's "in it" for the volunteer? How much "fun" does "Supporting an old language where the original developers have moved on to a newer and more interesting version of the language, but there's a bunch of complaining people who still want the old language to be supported but they aren't offering to pay for it" sound? I'd rather sit in the park reading a book or walk a dog or something. I mean, there's still people taking on COBOL contracts, because businesses consider their COBOL code to be important enough to keep maintained. But they sure as hell aren't "volunteering". They're getting paid rates that even bay area twenty-something FAANG-ers would be impressed by. If Blackrock or The Vanguard Group or equivalent decided they needed continued Python2 support because it was a critical dependency on their ETF platforms (and they'd been foolish enough to not heed the "Goddamn it, just fucking upgrade to Python3 already!" advice from the core team for about a decade), I'm sure they could whip out their chequebooks and agree to a rate that Guido himself would agree support Python2 for them. But I'd hope and expect Guido (or whoever in the core team would be suitable candidates to do this work) to hold out for genuinely life-changing numbers of zeros on those cheques. And if nobody is offering to write those cheques? Well maybe that says something about the seriousness of their complaints?
- CogitoCogito 7y ago
  > I'm finding it difficult to understand why anybody thinks supporting Python2 should be done by volunteers? I 100% agree. I was just responding to the parent post.

wongarsu 7y ago

Continuing a fork under the original name would be confusing to everyone and bad manners, aside from infringing the trademark. But nobody is stopping people from organising around a fork called "Omphalos - a Python 2 fork" or whatever

toyg 7y ago
Somebody has done just that already, it’s easily googleable. Nobody really cares though - why would you purposefully tie yourself to an objectively-inferior featureset, full of problems that have already been solved in py3? Because you can’t bear the use of parentheses for print, really?
- jsjohnst 7y ago
  > Because you can’t bear the use of parentheses for print, really? While I generally share your POV, it doesn’t do justice to the situation to trivialize the upgrade like that. Anyone with C based dependencies will have a rougher time (but not that “rough”) due to ABI changes. The harder userland change is string handling anyway (which isn’t that hard either), not parens on print.
  - toyg 7y ago
    You are right. I'm probably still shellshocked by the initial wave of complaints, so many years ago...
  - Drdrdrq 7y ago
    ...and those parenthesis are annoying as hell. :)
zajio1am 7y ago
It would not be fork when the original project (Python 2) is no longer developed. There are many cases of cooperative maintainership handover without name change and nobody cares. I understand using trademark as an advantage in cases of a hostile fork, but if the original maintainer no longer plan to do any bugfixing then it seems like a dick move.

avian 7y ago

Are you referring to that "Python 2.8" thing [1] that happened some years ago? A comment from PSF [2] makes it clear that they don't have any issue with people continuing to develop their Python 2 codebase further. It is what their open source explicitly permits after all. They do have issue with people using a trademarked name and not making it clear that their work isn't endorsed by the Python Foundation. [1] https://www.naftaliharris.com/blog/why-making-python-2.8/ https://www.naftaliharris.com/blog/why-making-python-2.8/ [2] https://news.ycombinator.com/item?id=13147972 https://news.ycombinator.com/item?id=13147972

CJefferson 7y ago
For me, if I want most existing python2 programs to work, I'd want to release my program as called "python", so "#!/usr/bin/env python" continued to work. If I'm not allowed to do that, then you are already adding a lot of friction to continuing to support existing python installs. Although, I wonder if you could claim you need to call it that for the programs to work?

XCabbage 7y ago

You've asserted this twice on this post, both times without any evidence. I Googled, couldn't find the threat you're basing the claim on, but DID find that the PSF Trademark Usage Policy (https://www.python.org/psf/trademarks/ https://www.python.org/psf/trademarks/) explicitly allows most sorts of freely distributed Python-related products to use the name without permission: > Use of the word "Python" in the names of freely distributed products like IronPython, wxPython, Python Extensions, etc. -- Allowed when referring to use with or suitability for the Python programming language. We can quibble about whether a Python 2 fork would technically meet the definition here, but it seems to me that it would meet it at least as much as IronPython does; going after such a fork would contradict the rule implied by the examples in this section, even if it doesn't unambiguously violate the definition. I think they've already granted the public the right to use the word "Python" in a Python 2 fork and couldn't successfully sue over it now even if they wanted to. What's your basis for suggesting that they've threatened to do so?

CJefferson 7y ago
Sorry, I shouldn't assume people know the same things I know. I know this has come up at least three times I've seen, but I'm having trouble finding them all. Here's one: https://github.com/naftaliharris/tauthon/issues/47 https://github.com/naftaliharris/tauthon/issues/47 In this case there was plans to call something py28, to which Guido replied "OK, bring in the lawyers".
- ZWoz 7y ago
  CJefferson probably refers that GvR comment (Though I don't see that strong language here): """ Since I was asked: The project's name (and its binary name) need to change. They are misleading. The rest looks acceptable according to Python's license. This is not an endorsement (far from it). """
  - CJefferson 7y ago
    Expand all comments. One is exactly what I quote.
- 7y ago