Re: Forking PyPI package

2014-06-06 Thread Akira Li
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

-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-06-05 Thread Wiktor
On Thu, 29 May 2014 15:54:09 -0600, Ian Kelly wrote:

 On Thu, May 29, 2014 at 1:40 AM, Chris Angelico ros...@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')
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-06-05 Thread Chris Angelico
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
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-06-05 Thread Wiktor
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')
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-05-29 Thread Chris Angelico
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
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-05-29 Thread Duncan Booth
Chris Angelico ros...@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: shamar...@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
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-05-29 Thread Chris Angelico
On Thu, May 29, 2014 at 5:56 PM, Duncan Booth
duncan.booth@invalid.invalid wrote:
 Chris Angelico ros...@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: shamar...@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
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-05-29 Thread Wiktor
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')
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-05-29 Thread Ian Kelly
On Thu, May 29, 2014 at 1:40 AM, Chris Angelico ros...@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?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-05-29 Thread Chris Angelico
On Fri, May 30, 2014 at 7:54 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
 On Thu, May 29, 2014 at 1:40 AM, Chris Angelico ros...@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
-- 
https://mail.python.org/mailman/listinfo/python-list


Forking PyPI package

2014-05-28 Thread 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
-- 
Best regards, Wiktor Matuszewski
'py{}@wu{}em.pl'.format('wkm', 'ka')
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Forking PyPI package

2014-05-28 Thread Terry Reedy

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

--
https://mail.python.org/mailman/listinfo/python-list