Forking PyPI package

[Wiktor]

Hello.

There's script pwdhash https://pypi.python.org/pypi/pwdhash.py/0.1.1,
which I always* wanted to port to Python 3. (* - well, i.e. 6 months ;-))
I'm using this hashing algorithm quite often for years in my browser
(Opera plugin), so I thought that it would be cool to have it as python
script.

It took me some time to make it work under Python 3, because I knew
nothing about str <-> bytes encoding, and this was biggest issue why
original script wasn't Py3 compatible. So now my version works, it even
supports Unicode characters (original JS script does that, but pwdhash.py
script doesn't), and now I'm planning to do simple GUI version, because
copying from console isn't very comfortable (and I couldn't find good [os
and other packages independent] solution to copy string to clipboard. Best
answer from here http://goo.gl/8V9Ba6 isn't working).
So, my point is, I think maybe it would be useful also to others.

I'm newbie not only to Python, but to programming in general, so I don't
know, what is best practice in OS programming community. How forking works.
How py2->py3 porting (by 3rd person) is realized in Pythonians community.
Can you suggest me something? I see few scenarios:

1) I'm trying to contact with original script's author, and send him my
propositions of changes in code. (Oh, one more thing: my code isn't
backward compatible, and I don't know Py2 that much to include all those
try/except, so it could be Py2+Py3 compatible). He decides, if he wants to
release it as Py3 only version, or combine it with his script and release
Py2+Py3 common version.

2) I'm not contacting with him, and I'm forking his project on GitHub
a) under the same name? - probably bad idea
b) under new name (e.g. py3pwdhash)?
Of course all credits about original author stay in code / setup.py.

2.1) After forking on GitHub, I'm creating new package on PyPI
a) under old name, but different version number, and new description?
b) under new name, to not confuse users?


So, what should I do?
I know, that maybe I shouldn't touch that script in first place and just
mail to author "Hey, would you please port it to Py3?", but I also treated
it as programming exercise, and I didn't think about consequences. ;-)

TIA

 

[Terry Reedy]

Hello.

There's script pwdhash https://pypi.python.org/pypi/pwdhash.py/0.1.1,
which I always* wanted to port to Python 3. (* - well, i.e. 6 months ;-))
I'm using this hashing algorithm quite often for years in my browser
(Opera plugin), so I thought that it would be cool to have it as python
script.

It took me some time to make it work under Python 3, because I knew
nothing about str <-> bytes encoding, and this was biggest issue why
original script wasn't Py3 compatible. So now my version works, it even
supports Unicode characters (original JS script does that, but pwdhash.py
script doesn't), and now I'm planning to do simple GUI version, because
copying from console isn't very comfortable (and I couldn't find good [os
and other packages independent] solution to copy string to clipboard. Best
answer from here http://goo.gl/8V9Ba6 isn't working).
So, my point is, I think maybe it would be useful also to others.

I'm newbie not only to Python, but to programming in general, so I don't
know, what is best practice in OS programming community. How forking works.
How py2->py3 porting (by 3rd person) is realized in Pythonians community.
Can you suggest me something? I see few scenarios:

1) I'm trying to contact with original script's author, and send him my
propositions of changes in code. (Oh, one more thing: my code isn't
backward compatible, and I don't know Py2 that much to include all those
try/except, so it could be Py2+Py3 compatible). He decides, if he wants to
release it as Py3 only version, or combine it with his script and release
Py2+Py3 common version.

2) I'm not contacting with him, and I'm forking his project on GitHub
a) under the same name? - probably bad idea
b) under new name (e.g. py3pwdhash)?
Of course all credits about original author stay in code / setup.py.

2.1) After forking on GitHub, I'm creating new package on PyPI
a) under old name, but different version number, and new description?
b) under new name, to not confuse users?


So, what should I do?
I know, that maybe I shouldn't touch that script in first place and just
mail to author "Hey, would you please port it to Py3?", but I also treated
it as programming exercise, and I didn't think about consequences. ;-)

Check the license of the code *and* contact the author if possible.

 

[Chris Angelico]

Deep in the code (pwdhash / pwdhash.py.egg-info / PKG-INFO):

Author: Lev Shamardin
Author-email: (e-mail address removed)
License: BSD

Still better to get in touch with the author, but he has actually stated
the license albeit in the most minimal way possible.

Ah! There you go then. Excellent.

In that case, the options I see are (in priority order):

1) Contact the author with your proposed changes, possibly with the
actual code or possibly leaving that for later, for inclusion in the
original project.

2) Ask the author if he's okay with you maintaining the Python 3
equivalent version as a separate project, under the same name.

3) If you can't get in touch with the author, just maintain that Py3
version, but maybe under a different name to avoid accidental
confusion.

ChrisA

 

[Wiktor]

So, what should I do?

Thanks guys, you're right. I'll contact the Lion. ;-)

Yes, I forgot to mention that pwdhash.py was published under BSD licence.
Without knowing that I wouldn't even consider forking it.

 

[Ian Kelly]

If you absolutely can't get in touch with him, the only option is to
go back to the original protocol and manually reimplement it,
completely ignoring this code. It's sad but true; some code dies
because of a trivial thing like "Oops, I forgot to actually say that
this is MIT-licensed".

The second part of that is that the code should actually *include* the
license text. Just writing "BSD license" somewhere on the website or
in package metadata is annoyingly common but somewhat questionable in
how a judge might interpret it. For instance, there at least four
different versions of the BSD license; which one did you mean?

 

[Chris Angelico]

The second part of that is that the code should actually *include* the
license text. Just writing "BSD license" somewhere on the website or
in package metadata is annoyingly common but somewhat questionable in
how a judge might interpret it. For instance, there at least four
different versions of the BSD license; which one did you mean?

Agreed. I tend to have a file called README or LICENSE in the main
source code directory that has license terms (in the case of a README,
the license will follow whatever else there is to say); that's
generally clear enough, without having to put a header on every single
source file.

I like to put both a short name and the full license text in there
(see eg https://github.com/Rosuav/Yosemite for which I use the MIT
license), so it's independent of random web sites - having nothing but
a link to the license text makes it that bit more vulnerable.

ChrisA

 

[Wiktor]

The second part of that is that the code should actually *include* the
license text. Just writing "BSD license" somewhere on the website or
in package metadata is annoyingly common but somewhat questionable in
how a judge might interpret it. For instance, there at least four
different versions of the BSD license; which one did you mean?

OK, it's almost week now and I have no response from author of that
script.

Just like you said, there's only inscription "BSD license" on PYPI
website, and in 'PKG-INFO' and 'setup.py' files. No 'readme.txt' or
'license.txt' is included. I can see now, that in fact it means that script
isn't published under any BSD license.

I guess, I'll try to do what Chris proposed. Forget about this
implementation and write python script from the scratch looking only at the
original JavaScript version. :-/

Thank you guys.

 

[Chris Angelico]

I guess, I'll try to do what Chris proposed. Forget about this
implementation and write python script from the scratch looking only at the
original JavaScript version. :-/

Sadly, that may be your only safe option.

Let this be a lesson to all: If you want something to be free
software, make it very clear, because "it looks like he meant that to
be open source" just isn't enough

ChrisA

 

[Wiktor]

Sadly, that may be your only safe option.

Let this be a lesson to all: If you want something to be free
software, make it very clear, because "it looks like he meant that to
be open source" just isn't enough

Lesson taken. ;-)
Interesting thing is, that for another 4 people, lack of license in this
script wasn't problem to publish its modified version. I've just searched
phrase "pwdhash" on GitHub, to simply check if someone else hadn't port
this script to Python3 earlier, or maybe ported it (with proper license) to
Python2 so I would have better start. And I've found practically the same
script here: https://github.com/ali01/pwdhash.py, forked then 3 times.
Of course I'm not going to act now "Oh, they could do that without
consequences, so why should I bother?" - no, I'm going to do this right (as
a good start in OS community) - but it feels awkward now. ;-)

 

[Akira Li]

Lesson taken. ;-)
Interesting thing is, that for another 4 people, lack of license in this
script wasn't problem to publish its modified version. I've just searched
phrase "pwdhash" on GitHub, to simply check if someone else hadn't port
this script to Python3 earlier, or maybe ported it (with proper license) to
Python2 so I would have better start. And I've found practically the same
script here: https://github.com/ali01/pwdhash.py, forked then 3 times.
Of course I'm not going to act now "Oh, they could do that without
consequences, so why should I bother?" - no, I'm going to do this right (as
a good start in OS community) - but it feels awkward now. ;-)

Have you tried to open an issue about clarifying the license terms [1] ?

[1]: https://github.com/abbot/pwdhash/issues/new

Or better yet, submit a pull request that specifies the license to the
standard you need?

I've dealt with the author in the past. I see no reason, he would refuse
to accept PR if license=BSD in setup.py is not enough.