Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
From: Martin v. Löwis [EMAIL PROTECTED] Donovan Baarda wrote: This patch keeps the current md5c.c, md5module.c files and adds the following; _hashopenssl.c, hashes.py, md5.py, sha.py. [...] If all we wanted to do was fix the md5 module If we want to fix the licensing issues with the md5 module, this patch does not help at all, as it keeps the current md5 module (along with its licensing issues). So any patch to solve the problem will need to delete the code with the questionable license. It maybe half fixes it in that if Python is happy with the RSA one, they can continue to include it, and if Debian is unhappy with it, they can remove it and build against openssl. It doesn't fully fix the license problem. It is still worth considering because it doesn't make it worse, and it does allow Python to use much faster implementations and support other digest algorithms when openssl is available. Then, the approach in the patch breaks the promise that the md5 module is always there. It would require that OpenSSL is always there - a promise that we cannot make (IMO). It would be better if found an alternative md5c.c. I found one that was the libmd implementation that someone mildly tweaked and then slapped an LGPL on. I have a feeling that would make the lawyers tremble more than the public domain libmd one, unless they are happy that someone else is prepared to wear the grief for slapping a LGPL onto something public domain. Probably the best at the moment is the sourceforge one, which is listed as having a zlib/libpng licence. Donovan Baardahttp://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Fri, Feb 18, 2005 at 10:06:24AM +0100, Martin v. L?wis wrote: Donovan Baarda wrote: This patch keeps the current md5c.c, md5module.c files and adds the following; _hashopenssl.c, hashes.py, md5.py, sha.py. [...] If all we wanted to do was fix the md5 module If we want to fix the licensing issues with the md5 module, this patch does not help at all, as it keeps the current md5 module (along with its licensing issues). So any patch to solve the problem will need to delete the code with the questionable license. Then, the approach in the patch breaks the promise that the md5 module is always there. It would require that OpenSSL is always there - a promise that we cannot make (IMO). I'm aware of that. My goals are primarily to get a good openssl based hashes/digest module going to be used instead of the built in implementations when openssl available because openssl is -so- much faster. Fixing the debian instigated md5 licensing issue is secondary and is something I'll get to later on after i work on the fun stuff. And as Donovan has said, the patch already does present debian with the option of dropping that md5 module and using the openssl derived one instead if they're desperate. based on laziness winning and the issue being so minor i hope they just wait for a patch from me that replaces the md5c.c with one of the acceptably licensed ones for their 2.3/2.4 packages. -g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Wed, 2005-02-16 at 22:53 -0800, Gregory P. Smith wrote: fyi - i've updated the python sha1/md5 openssl patch. it now replaces the entire sha and md5 modules with a generic hashes module that gives access to all of the hash algorithms supported by OpenSSL (including appropriate legacy interface wrappers and falling back to the old code when compiled without openssl). https://sourceforge.net/tracker/index.php?func=detailaid=1121611group_id=5470atid=305470 I don't quite like the module name 'hashes' that i chose for the generic interface (too close to the builtin hash() function). Other suggestions on a module name? 'digest' comes to mind. I just had a quick look, and have these comments (psedo patch review?). Apologies for the noise on the list... DESCRIPTION === This patch keeps the current md5c.c, md5module.c files and adds the following; _hashopenssl.c, hashes.py, md5.py, sha.py. The old md5 and sha extension modules get replaced by hashes.py, md5.py, and sha.py python modules that leverage off _hash (openssl) or _md5 and _sha (no openssl) extension modules. The new _hash extension module wraps the high level openssl EVP interface, which uses a string parameter to indicate what type of message digest algorithm to use. The advantage of this is it makes all openssl supported digests available, and if openssl adds more, we get them for free. A disadvantage of this is it is an abstraction level above the actual md5 and sha implementations, and this may add overheads. These overheads are probably negligible compared to the actual implementation speedups. The new _md5 and _sha extension modules are simply re-named versions of the old md5 and sha modules. The hashes.py module acts as an import wrapper for _hash, and falls back to using _md5 and _sha modules if _hash is not available. It provides an EVP style API (string hash name parameter), that supports only md5 and sha hashes if openssl is not available. The new md5.py and sha.py modules simply use hash.py. COMMENTS The introduction of a hashes module with a new API that supports many different digests (provided openssl is available) is extending Python, not just fixing the licenses of md5 and sha modules. If all we wanted to do was fix the md5 module, a simpler solution would be to change the md5c.c API to match openssl's implementation, and make md5module.c use it, conditionally compiling against md5c.c or linking against openssl in setup.py. A similar approach could be used for sha, but would require stripping the sha implementation out of shamodule.c I am mildly of concerned about the namespace/filespace clutter introduced by this implementation... it feels unnecessary, as does the tangled dependencies between them. With openssl, hashes.py duplicates the functionality of _hash. Without openssl, md5.py and sha.py duplicate _md5 and _sha, via a roundabout route through hash.py. The python wrappers seem overly complicated, with things like def new(name, string=None): if string: return _hash.new(name) else: return _hash.new.(name,string) being common where the following would suffice; def new(name,string=): return _hash.new(name,string) I think this is because _hash.new() uses an optional string parameter, but I have a feeling a C update with a zero length string is faster than this Python if. If it was a concern, the C implementation could check the value of the string length before calling update. Given the convenience methods for different hashes in hashes.py (which incidentally look like they are only available when _hash is not available... something else that needs fixing), the md5.py module could be simply coded as; from hashes import md5 new = md5 Despite all these nit-picks, it looks pretty good. It is orders of magnitude better than any of the other non-existent solutions, including the one I didn't code :-) -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
fyi - i've updated the python sha1/md5 openssl patch. it now replaces the entire sha and md5 modules with a generic hashes module that gives access to all of the hash algorithms supported by OpenSSL (including appropriate legacy interface wrappers and falling back to the old code when compiled without openssl). https://sourceforge.net/tracker/index.php?func=detailaid=1121611group_id=5470atid=305470 I don't quite like the module name 'hashes' that i chose for the generic interface (too close to the builtin hash() function). Other suggestions on a module name? 'digest' comes to mind. -greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
Phillip J. Eby wrote: Isn't the PSF somewhere in between? I mean, in theory we are supposed to be tracking stuff, but in practice there's no contributor agreement for CVS committers ala Zope Corp.'s approach. That is not true, see http://www.python.org/psf/contrib.html We certainly don't have forms from all contributors, yet, but we are working on it. So in some sense right now, Python depends largely on the implied promise of its contributors to license their contributions under the same terms as Python. ISTM that if somebody's lawyer is worried about whether Python contains pseudo-public domain code, they should be downright horrified by the absence of a paper trail on the rest. But IANAM (I Am Not A Marketer), either. :) And indeed, they are horrified. Right now, we can tell them we are working on it - so I would like to see that any change that we make to improve the PSF's legal standing. Adding code which was put into the public domain makes it worse (atleast in the specific case - we are clearly allowed to do what we do with the current md5 code; for the newly-proposed code, it is not so clear, even if you think it is likely we would win in court). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
At 12:57 AM 2/12/05 +0100, Martin v. Löwis wrote: Phillip J. Eby wrote: I personally can't see how taking the reasonable interpretation of a public domain declaration can lead to any difficulties, but then, IANAL. The ultimate question is whether we could legally relicense such code under the Python license, ie. remove the PD declaration, and attach the Python license to it. I'm sure somebody would come along and claim you cannot do that, and because you did, I cannot use your code, because it is not legally trustworthy; people would say the same if the PD declaration would stay around. Right, but now we've moved off the legality and into marketing, which is an even less sane subject in some ways. The law at least has certain checks and balances built into it, but in marketing, people's irrationality knows no bounds. ;) It might be, but that is irrelevant for open source projects that include contributions. Either they don't care too much about such things, in which case anything remotely free would be acceptable, or they are very nit-picking, in which case you need a good record for any contribution you ever received. Isn't the PSF somewhere in between? I mean, in theory we are supposed to be tracking stuff, but in practice there's no contributor agreement for CVS committers ala Zope Corp.'s approach. So in some sense right now, Python depends largely on the implied promise of its contributors to license their contributions under the same terms as Python. ISTM that if somebody's lawyer is worried about whether Python contains pseudo-public domain code, they should be downright horrified by the absence of a paper trail on the rest. But IANAM (I Am Not A Marketer), either. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Feb 11, 2005, at 6:11 PM, Donovan Baarda wrote: G'day again, From: Gregory P. Smith [EMAIL PROTECTED] I think it would be cleaner and simpler to modify the existing md5module.c to use the openssl md5 layer API (this is just a search/replace to change the function names). The bigger problem is deciding what/how/whether to include the openssl md5 implementation sources so that win32 can use them. yes, that is all i was suggesting. win32 python is already linked against openssl for the socket module ssl support, having the md5 and sha1 modules depend on openssl should not cause a problem. IANAL... I have too much common sense, so I won't argue licences :-) So is openssl already included in the Python sources, or is it just a dependency? I had a quick look and couldn't find it so it must be a dependency. Given that Python is already dependant on openssl, it makes sense to change md5sum to use it. I have a feeling that openssl internally uses md5, so this way we wont link against two different md5sum implementations. It is an optional dependency that is used when present (read: not just win32). The sources are not included with Python. OpenSSL does internally have an implementation of md5 (and sha1, among other things). -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
G'day again, From: Gregory P. Smith [EMAIL PROTECTED] I think it would be cleaner and simpler to modify the existing md5module.c to use the openssl md5 layer API (this is just a search/replace to change the function names). The bigger problem is deciding what/how/whether to include the openssl md5 implementation sources so that win32 can use them. yes, that is all i was suggesting. win32 python is already linked against openssl for the socket module ssl support, having the md5 and sha1 modules depend on openssl should not cause a problem. IANAL... I have too much common sense, so I won't argue licences :-) So is openssl already included in the Python sources, or is it just a dependency? I had a quick look and couldn't find it so it must be a dependency. Given that Python is already dependant on openssl, it makes sense to change md5sum to use it. I have a feeling that openssl internally uses md5, so this way we wont link against two different md5sum implementations. Donovan Baardahttp://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
Phillip J. Eby wrote: I personally can't see how taking the reasonable interpretation of a public domain declaration can lead to any difficulties, but then, IANAL. The ultimate question is whether we could legally relicense such code under the Python license, ie. remove the PD declaration, and attach the Python license to it. I'm sure somebody would come along and claim you cannot do that, and because you did, I cannot use your code, because it is not legally trustworthy; people would say the same if the PD declaration would stay around. It is important for us that our users (including our commercial users) trust that Python has a clear legal track record. For such users, it is irrelevant whether you think that a litigation of the actual copyright holder would have any chance to stand in court, or whether such action is even likely. So for some users, replacing RSA-copyrighted-and-licensed code with PD-declared-and-unlicensed code makes Python less trustworthy. Clearly, for Debian, it is exactly the other way 'round. So I have rejected the patch, preserving the status quo, until a properly licensed open source implementation of md5 arrives. Until then, Debian will have to patch Python. But again, IANAL, certainly not a famous one like Mr. Rosen. I *am* most curious to know why his article seems to imply that a promise not to sue someone for copyright infringement isn't a valid defense against such a suit It might be, but that is irrelevant for open source projects that include contributions. Either they don't care too much about such things, in which case anything remotely free would be acceptable, or they are very nit-picking, in which case you need a good record for any contribution you ever received. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
At 02:09 AM 2/12/05 +0100, Martin v. Löwis wrote: Phillip J. Eby wrote: Isn't the PSF somewhere in between? I mean, in theory we are supposed to be tracking stuff, but in practice there's no contributor agreement for CVS committers ala Zope Corp.'s approach. That is not true, see http://www.python.org/psf/contrib.html We certainly don't have forms from all contributors, yet, but we are working on it. So in some sense right now, Python depends largely on the implied promise of its contributors to license their contributions under the same terms as Python. ISTM that if somebody's lawyer is worried about whether Python contains pseudo-public domain code, they should be downright horrified by the absence of a paper trail on the rest. But IANAM (I Am Not A Marketer), either. :) And indeed, they are horrified. Right now, we can tell them we are working on it - so I would like to see that any change that we make to improve the PSF's legal standing. Adding code which was put into the public domain makes it worse (atleast in the specific case - we are clearly allowed to do what we do with the current md5 code; for the newly-proposed code, it is not so clear, even if you think it is likely we would win in court). Thanks for the clarifications. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
At 03:46 PM 2/11/05 -0500, Tim Peters wrote: If Larry is correct, it isn't legally possible for an individual in the US to disclaim copyright, regardless what they may say or sign. The danger then is that accepting software that purports to be free of copyright can come back to bite you, if the author later changes their mind (from your POV; the claim is that from US law's POV, nothing has actually changed, since the author never actually gave up copyright to begin with). The very fact that this argument exists underscores the desirability of only accepting software with an explicit license, spelling out the copyright holder's intents wrt distribution, modification, etc. Then you're just in legal mud, instead of legal quicksand. And as long as we're flailing about in a substance which may include, but is not limited to, mud and/or quicksand or other flailing-suitable legal substances, it should be pointed out that even though software presented by its owner to be in the public domain is technically still copyright by that individual, the odds of them successfully prosecuting a copyright enforcement action might be significantly narrowed, due to the doctrine of promissory estoppel. Promissory estoppel is basically the idea that one-sided promises *are* enforceable when somebody reasonably relies on them and is injured by the withdrawal. IBM, for example, has pled in its defense against SCO that SCO's distribution of its so-called proprietary code under the GPL constituted a reasonable promise that others were free to use the code under the terms of the GPL, and that IBM further relied on that promise. Ergo, they are claiming, SCO's promise is enforceable by law. Of course, SCO v. IBM hasn't had any judgments yet, certainly not on that subject, and maybe never will. But it's important to know that the law *does* have some principles like this that allow overriding the more egregiously insane aspects of the law. :) Oh, also, if somebody decides to back out on their dedication to the public domain, and you can show that they did it on purpose, then that's unclean hands and possibly copyright abuse as well. Just to muddy up the waters a little bit. :) Obviously, the PSF should follow its own lawyer's advice, but it seemed to me that the point of Mr. Rosen's article was more to advise people releasing software to use a license that allows them to disclaim warranties. I personally can't see how taking the reasonable interpretation of a public domain declaration can lead to any difficulties, but then, IANAL. I'm surprised, however, that he didn't even touch on promissory estoppel, if there is some reason he believes that the doctrine wouldn't apply to a software license. Heck, I was under the impression that free copyright licenses in general got their effect by way of promissory estoppel, since such licenses are always one-sided promises. The GPL in particular makes an explicit point of this, even though it doesn't use the words promissory estoppel. The point is that the law doesn't allow you to copy, so the license is your defense against a charge of copyright infringement. Therefore, even Rosen's so-called Give it away license is enforceable, in the sense that the licensor should be barred from taking action against someone taking the license at face value. Rosen also says, Under basic contract law, a gift cannot be enforced. The donor can retract his gift at any time, for any reason. If this were true, I could give you a watch for Christmas and then sue you to make you give it back, so I'm not sure what he's getting at here. But again, IANAL, certainly not a famous one like Mr. Rosen. I *am* most curious to know why his article seems to imply that a promise not to sue someone for copyright infringement isn't a valid defense against such a suit, because that would seem to imply that *no* free software license is valid, including the GPL or the PSF license! (Surely those gifts can be retracted too, no?) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Sat, Feb 12, 2005 at 01:54:27PM +1100, Donovan Baarda wrote: Are there any potential problems with making the md5sum module availability optional in the same way as this? The md5 module has been a standard module for a long time; making it optional in the next version of Python isn't possible. We'd have to require OpenSSL to compile Python. I'm happy to replace the MD5 and/or SHA implementations with other code, provided other code with a suitable license can be found. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Sat, 2005-02-12 at 08:37, A.M. Kuchling wrote: The md5 module has been a standard module for a long time; making it optional in the next version of Python isn't possible. We'd have to require OpenSSL to compile Python. I totally agree. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Sat, Feb 12, 2005 at 08:37:21AM -0500, A.M. Kuchling wrote: On Sat, Feb 12, 2005 at 01:54:27PM +1100, Donovan Baarda wrote: Are there any potential problems with making the md5sum module availability optional in the same way as this? The md5 module has been a standard module for a long time; making it optional in the next version of Python isn't possible. We'd have to require OpenSSL to compile Python. I'm happy to replace the MD5 and/or SHA implementations with other code, provided other code with a suitable license can be found. agreed. it can not be made optional. What I'd prefer (and will do if i find the time) is to have the md5 and sha1 module use OpenSSLs implementations when available. Falling back to their built in ones when openssl isn't present. That way its always there but uses the much faster optimized openssl algorithms when they exist. -g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
Donovan Baarda writes: On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: The md5.h/md5c.c files allow copy and use, but no modification of the files. There are some alternative implementations, i.e. in glibc, openssl, so a replacement should be sage. Any other requirements when considering a replacement? One thing to consider is degree of difficulty :-) Matthias I believe the plan for md5 and sha1 and such is to use the much faster openssl versions in the future (based on a long thread debating future interfaces to such things on python-dev last summer). That'll sidestep any tedious license issue and give a better implementation at the same time. i don't believe anyone has taken the time to make such a patch yet. I wasn't around for that discussion. There are two viable replacements for the RSA implementation currently used; libmd http://www.penguin.cz/~mhi/libmd/ openssl http://www.openssl.org/. The libmd implementation is by Colin Plumb and has the licence; This code is in the public domain; do with it what you wish. The API is identical to the RSA implementation and BSD world's libmd and hence is a drop in replacement. This implementation is faster than the RSA implementation. [...] Currently md5c.c is included in the python sources. The libmd implementation has a drop in replacement for md5c.c. The openssl implementation is a complicated tangle of Makefile expanded template code that would be harder to include in the Python sources. I would prefer that one as a short term solution. Patch at #1118602. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Fri, 11 Feb 2005 12:55:02 +0100, Matthias Klose [EMAIL PROTECTED] wrote: Currently md5c.c is included in the python sources. The libmd implementation has a drop in replacement for md5c.c. The openssl implementation is a complicated tangle of Makefile expanded template code that would be harder to include in the Python sources. I would prefer that one as a short term solution. Patch at #1118602. Unfortunately a license that says it is in the public domain is unacceptable (and should be for Debian, too). That is to say, it's not possible for someone to claim that something they produce is in the public domain. See http://www.linuxjournal.com/article/6225 Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
I think it would be cleaner and simpler to modify the existing md5module.c to use the openssl md5 layer API (this is just a search/replace to change the function names). The bigger problem is deciding what/how/whether to include the openssl md5 implementation sources so that win32 can use them. yes, that is all i was suggesting. win32 python is already linked against openssl for the socket module ssl support, having the md5 and sha1 modules depend on openssl should not cause a problem. -greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
Jeremy writes: Unfortunately a license that says it is in the public domain is unacceptable (and should be for Debian, too). That is to say, it's not possible for someone to claim that something they produce is in the public domain. See http://www.linuxjournal.com/article/6225 Not quite true. It would be a bit off-topic to discuss on this list so I will simply point you to: http://creativecommons.org/license/publicdomain-2 ...which is specifically designed for the US legal system. It _IS_ possible for someone to produce something in the public domain, it just isn't as easy as some people think (just saying it doesn't necessarily make it so (at least under US law)) and it may not be a good idea. I would expect that if something truly WERE in the public domain, then it would be acceptable for Python (and for Debian too, for that matter). I can't comment on whether this applies to libmd. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: The md5.h/md5c.c files allow copy and use, but no modification of the files. There are some alternative implementations, i.e. in glibc, openssl, so a replacement should be sage. Any other requirements when considering a replacement? One thing to consider is degree of difficulty :-) Matthias I believe the plan for md5 and sha1 and such is to use the much faster openssl versions in the future (based on a long thread debating future interfaces to such things on python-dev last summer). That'll sidestep any tedious license issue and give a better implementation at the same time. i don't believe anyone has taken the time to make such a patch yet. I wasn't around for that discussion. There are two viable replacements for the RSA implementation currently used; libmd http://www.penguin.cz/~mhi/libmd/ openssl http://www.openssl.org/. The libmd implementation is by Colin Plumb and has the licence; This code is in the public domain; do with it what you wish. The API is identical to the RSA implementation and BSD world's libmd and hence is a drop in replacement. This implementation is faster than the RSA implementation. The openssl implementation has an apache style license. The API is almost the same but slightly different to the RSA API, so it would require a little bit of work to make it fit. This implementation is the fastest currently available, as it includes many platform specific optimisations for a large range of platforms. Currently md5c.c is included in the python sources. The libmd implementation has a drop in replacement for md5c.c. The openssl implementation is a complicated tangle of Makefile expanded template code that would be harder to include in the Python sources. In the Linux world, openssl is starting to become ubiquitous, so not including it and statically or even dynamically linking against it is feasible. However, using Python in other lands will probably require something to be included. Long term, I think openssl is the way to go. Short term, libmd is a painless replacement that gets around the licencing issues. I have been using the libmd API stuff for md4 in librsync, and am looking at migrating to the openssl API. If people hassle me, I could probably do the openssl API migration for Python, but I'm not sure what the best approach would be to including the source in Python sources. FWIW, I also have an md4sum module and md4c.c implementation that I'm happy to contribute to Python (done for pysysnc). -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Feb 10, 2005, at 9:15 PM, Donovan Baarda wrote: On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: The md5.h/md5c.c files allow copy and use, but no modification of the files. There are some alternative implementations, i.e. in glibc, openssl, so a replacement should be sage. Any other requirements when considering a replacement? One thing to consider is degree of difficulty :-) Matthias I believe the plan for md5 and sha1 and such is to use the much faster openssl versions in the future (based on a long thread debating future interfaces to such things on python-dev last summer). That'll sidestep any tedious license issue and give a better implementation at the same time. i don't believe anyone has taken the time to make such a patch yet. I wasn't around for that discussion. There are two viable replacements for the RSA implementation currently used; libmd http://www.penguin.cz/~mhi/libmd/ openssl http://www.openssl.org/. -- In the Linux world, openssl is starting to become ubiquitous, so not including it and statically or even dynamically linking against it is feasible. However, using Python in other lands will probably require something to be included. Long term, I think openssl is the way to go. Short term, libmd is a painless replacement that gets around the licencing issues. OpenSSL is also ubiquitous on Mac OS X (as a shared lib): Mac OS X 10.2.8 has OpenSSL 0.9.6i Feb 19 2003 Mac OS X 10.3.8 has OpenSSL 0.9.7b 10 Apr 2003 One possible alternative would be to bring in something like PyOpenSSL http://pyopenssl.sourceforge.net/ and just rewrite the md5 (and sha?) extensions as Python modules that use that API. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Thu, 2005-02-10 at 21:30 -0500, Bob Ippolito wrote: On Feb 10, 2005, at 9:15 PM, Donovan Baarda wrote: On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: [...] One possible alternative would be to bring in something like PyOpenSSL http://pyopenssl.sourceforge.net/ and just rewrite the md5 (and sha?) extensions as Python modules that use that API. Only problem with this, is pyopenssl doesn't yet include any mdX or sha modules. -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Feb 10, 2005, at 9:50 PM, Donovan Baarda wrote: On Thu, 2005-02-10 at 21:30 -0500, Bob Ippolito wrote: On Feb 10, 2005, at 9:15 PM, Donovan Baarda wrote: On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: [...] One possible alternative would be to bring in something like PyOpenSSL http://pyopenssl.sourceforge.net/ and just rewrite the md5 (and sha?) extensions as Python modules that use that API. Only problem with this, is pyopenssl doesn't yet include any mdX or sha modules. My bad, how about M2Crypto http://sandbox.rulemaker.net/ngps/m2/ then? This one supports message digests and is more license compatible with Python to boot. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Thu, 2005-02-10 at 23:13 -0500, Bob Ippolito wrote: On Feb 10, 2005, at 9:50 PM, Donovan Baarda wrote: On Thu, 2005-02-10 at 21:30 -0500, Bob Ippolito wrote: [...] Only problem with this, is pyopenssl doesn't yet include any mdX or sha modules. My bad, how about M2Crypto http://sandbox.rulemaker.net/ngps/m2/ then? This one supports message digests and is more license compatible with Python to boot. [...] This one does have md5 support, but the Python API is rather different from the current python md5sum API. It hooks into the slightly higher level MVP openssl layer, rather than the lower level md5 layer. Hooking into the MVP layer pretty much requires including all the openssl message digest implementations (which may or may not be a good idea). It also uses SWIG to generate the extension module. I don't think anything else in Python itself uses SWIG, so starting to use it would introduce a Build Dependency. I think it would be cleaner and simpler to modify the existing md5module.c to use the openssl md5 layer API (this is just a search/replace to change the function names). The bigger problem is deciding what/how/whether to include the openssl md5 implementation sources so that win32 can use them. -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
Maybe some ambitious PSF activitst could contact Roskind and Steve Kirsch and see if they know who at Disney to talk to... Or maybe the Disney guys who were at PyCon last year could help. Jeremy On Tue, 8 Feb 2005 15:37:50 -0500, Tim Peters [EMAIL PROTECTED] wrote: [Matthias Klose] A Debian user pointed out (http://bugs.debian.org/293932), that the current license for the Python profiler is not conforming to the DFSG (Debian free software guidelines). http://www.python.org/doc/current/lib/node829.html states This permission is explicitly restricted to the copying and modification of the software to remain in Python, compiled Python, or other languages (such as C) wherein the modified or derived code is exclusively imported into a Python module. ... - Does somebody knows about the history of this license, why it is more restricted than the Python license? Simply because that's the license Jim Roskind slapped on it when he contributed this code 10 years ago. I imagine (but don't know) that Guido looked at it, thought hmm -- shouldn't be a problem for Python's users, and so accepted it. - Is there a chance to change the license for these two modules (profile.py, pstats.py)? Not unless some remnant of InfoSeek Corp can be found, since they're the copyright holder (their work, their license). Alas, Jim Roskind hasn't been seen in the Python world this century. OTOH, if InfoSeek has vanished, it's unlikely they'll be suing anyone. Given how Python-specific profile.py and pstats.py are, it's hard for me to imagine anyone wanting to make a derivative that isn't imported into a Python module. In that respect it seems like a license clause that forbids you to run the software while the tip of your tongue is licking the back of your own neck. Still, if that matters, perhaps Debian will need to leave these modules out. Bold ahem users will still be able to grab them from any number of other places. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
