Bug#293932: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Tue, 8 Feb 2005 15:52:29 -0500, Jeremy Hylton [EMAIL PROTECTED] wrote: 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. I contacted Jim. His response follows: --- I'm a strong supporter of Opensource software, but I'm probably not going to be able to help you very much. I could be much more helpful with understanding the code or its use ;-). To summarize what I'll say: I don't own the rights to this stuff. ... but I don't believe there are any patents that I was ever involved with that might encumber this work. I would note that my profiler code is really very rarely used in commercial products, and it is much more typically used by developers (I guess a developer toolkit, if sold, would use it). I'm pretty delighted that the code has found so much use by developers over the years. As I noted in the intro to the documentation, I had only been coding in Python for 3 weeks when I wrote it. On the positive side, it exposed many weaknesses in many developer's code (including our own at InfoSeek), as well as in core Python code (subtle bugs in the interpreter) that surely helped everyone. Even though I was a newbie, It was VERY carefully crafted,, and I'd expect that it would take a fair amount of effort to reproduce it (and that is is probably why it has not been changed much... or at least no one told me when they changed/fixed it ;-) ). With regard to why I probably can't help much. First off, InfoSeek (holder of the copyright) was bought by Disney, and I don't know what if anything has eventually become of the tradename. There is a chance that Disney owns the rights... and I have no idea who to ask there :-/. Second, I took a look at the Copyright, and it sure seems pretty permissive. I'm amazed if folks want something more permissive. This is what I found on the web for it: Copyright © 1994, by InfoSeek Corporation, all rights reserved. Written by James Roskind.10.1 Permission to use, copy, modify, and distribute this Python software and its associated documentation for any purpose (subject to the restriction in the following sentence) without fee is hereby granted, provided that the above copyright notice appears in all copies, and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of InfoSeek not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. 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. INFOSEEK CORPORATION DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INFOSEEK CORPORATION BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. As I recall, I probably personally created the terms of the above license. I used a similar license on my C/C++ grammar, and Infoseek just added a bunch of wording to be sure that they were not at risk, and that their name would not be used in vain (or in advertising material). I think they were also interested in limiting its use to Python but I don't think that is a concern that would bother you. I read the link you directed me to, and its primary focus seemed ot be on patents for related or included technology. I don't believe that infoseek applied for or got any patents in this area (and certainly if they did so without my name, it would probably invalidate the patent), and I'm sure I didn't get any patents in this area at Netscape/AOL. In fact I don't think I got any patents back in 1994 or 1995. My only prior patent dated back to about 1983 (a hardware patent) that has since expired. I have some patents since (roughly) 1995, and even though I don't think any of them relate to profiling (though some did relate to languages, or more specifically, security in languages), I wouldn't want to mess with assigning rights to any of those patents, as they belong to AOL/Netscape. Here again, to my knowledge, none of my patents relate in any way to this area (profiling). Sadly, if they did, I would not have the right to assign them. I'm sure you're just doing your job, and following through by dotting all the I's and crossing all T's. My suggestion is to (as you said) work around the issue. You could always re-write the code from scratch, as the approaches are not rocket science and are pretty thoroughly explained. I wouldn't suggest it unless
Bug#293932: [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
G'day, From: Bob Ippolito [EMAIL PROTECTED] On Feb 11, 2005, at 6:11 PM, Donovan Baarda wrote: [...] 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. Are there any potential problems with making the md5sum module availability optional in the same way as this? OpenSSL does internally have an implementation of md5 (and sha1, among other things). Yeah, I know, that's why it could be used for the md5sum module :-) What I meant was a Python application using ssl sockets and the md5sum module will effectively have two different md5sum implementations in memory. Using the openssl md5sum for the md5sum module will make it leaner, as well as faster. Donovan Baardahttp://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
On Fri, 2005-02-11 at 17:15 +1100, Donovan Baarda wrote: [...] 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. Thinking about it, probably the best way is to include the libmd md5c.c modified to use the openssl API, and then use configure to check for and use openssl if it is available. That way win32 could use the provided md5c.c, and other platforms could use the faster openssl. -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293932: [Python-Dev] license issues with profiler.py and md5.h/md5c.c
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? 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. -g -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
