Re: Forking PyPI package
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
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
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
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
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
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
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
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
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
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
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
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