Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #72204 > unrolled thread

Forking PyPI package

Back to article view | Back to comp.lang.python

Contents

  Forking PyPI package Wiktor <look@signature.invalid> - 2014-05-29 02:31 +0200
    Re: Forking PyPI package Terry Reedy <tjreedy@udel.edu> - 2014-05-28 22:06 -0400
    Re: Forking PyPI package Chris Angelico <rosuav@gmail.com> - 2014-05-29 17:40 +1000
      Re: Forking PyPI package Duncan Booth <duncan.booth@invalid.invalid> - 2014-05-29 07:56 +0000
        Re: Forking PyPI package Chris Angelico <rosuav@gmail.com> - 2014-05-29 18:06 +1000
    Re: Forking PyPI package Wiktor <look@signature.invalid> - 2014-05-29 10:49 +0200
    Re: Forking PyPI package Ian Kelly <ian.g.kelly@gmail.com> - 2014-05-29 15:54 -0600
      Re: Forking PyPI package Wiktor <look@signature.invalid> - 2014-06-05 18:56 +0200
        Re: Forking PyPI package Chris Angelico <rosuav@gmail.com> - 2014-06-06 03:37 +1000
          Re: Forking PyPI package Wiktor <look@signature.invalid> - 2014-06-06 02:15 +0200
            Re: Forking PyPI package Akira Li <4kir4.1i@gmail.com> - 2014-06-06 15:26 +0400
    Re: Forking PyPI package Chris Angelico <rosuav@gmail.com> - 2014-05-30 10:26 +1000

#72204 — Forking PyPI package

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
-- 
Best regards,     Wiktor Matuszewski
'py{}@wu{}em.pl'.format('wkm', 'ka')

[toc] | [next] | [standalone]

#72209

On 5/28/2014 8:31 PM, Wiktor wrote:
> 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.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#72223

On Thu, May 29, 2014 at 10:31 AM, Wiktor <look@signature.invalid> wrote:
> 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?

Unfortunately, you're not legally allowed to just fork it and make
your own derivative work, because the original author hasn't put
license terms on the project. As it's been posted on github, we can
guess that the intention was probably for it to be open source, but
your first action has to be to contact the author and ask about
license.

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".

(At least, I can't see a license anywhere on github there. If you can
find another copy of the same code somewhere else, posted by its
author, and including a license, then your job is easier.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#72224

Chris Angelico <rosuav@gmail.com> wrote:

> 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".
> 
> (At least, I can't see a license anywhere on github there. If you can
> find another copy of the same code somewhere else, posted by its
> author, and including a license, then your job is easier.)

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

  Author: Lev Shamardin
  Author-email: shamardin@gmail.com
  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.

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#72226

On Thu, May 29, 2014 at 5:56 PM, Duncan Booth
<duncan.booth@invalid.invalid> wrote:
> Chris Angelico <rosuav@gmail.com> wrote:
>
>> 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".
>>
>> (At least, I can't see a license anywhere on github there. If you can
>> find another copy of the same code somewhere else, posted by its
>> author, and including a license, then your job is easier.)
>
> Deep in the code (pwdhash / pwdhash.py.egg-info / PKG-INFO):
>
>   Author: Lev Shamardin
>   Author-email: shamardin@gmail.com
>   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

[toc] | [prev] | [next] | [standalone]

#72230

On Thu, 29 May 2014 02:31:56 +0200, Wiktor wrote:

>   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.

-- 
Best regards,     Wiktor Matuszewski
'py{}@wu{}em.pl'.format('wkm', 'ka')

[toc] | [prev] | [next] | [standalone]

#72255

On Thu, May 29, 2014 at 1:40 AM, Chris Angelico <rosuav@gmail.com> wrote:
> 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?

[toc] | [prev] | [next] | [standalone]

#72730

On Thu, 29 May 2014 15:54:09 -0600, Ian Kelly wrote:

> On Thu, May 29, 2014 at 1:40 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> 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?

  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.  
  
-- 
Best regards,     Wiktor Matuszewski
'py{}@wu{}em.pl'.format('wkm', 'ka')

[toc] | [prev] | [next] | [standalone]

#72740

On Fri, Jun 6, 2014 at 2:56 AM, Wiktor <look@signature.invalid> wrote:
>   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

[toc] | [prev] | [next] | [standalone]

#72799

On Fri, 6 Jun 2014 03:37:56 +1000, Chris Angelico wrote:

> On Fri, Jun 6, 2014 at 2:56 AM, Wiktor <look@signature.invalid> wrote:
>>   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 :(

  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. ;-)

-- 
Best regards,     Wiktor Matuszewski
'py{}@wu{}em.pl'.format('wkm', 'ka')

[toc] | [prev] | [next] | [standalone]

#72835

Wiktor <look@signature.invalid> writes:

> On Fri, 6 Jun 2014 03:37:56 +1000, Chris Angelico wrote:
>
>> On Fri, Jun 6, 2014 at 2:56 AM, Wiktor <look@signature.invalid> wrote:
>>>   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 :(
>
>   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.


--
akira

[toc] | [prev] | [next] | [standalone]

#72264

On Fri, May 30, 2014 at 7:54 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Thu, May 29, 2014 at 1:40 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> 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?

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web