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
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/ ___ 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
[Python-Dev] Re: license issues with profiler.py and md5.h/md5c.c
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > http://www.python.org/psf/contrib.html After reading this page and pages linked thereto, I get the impression that you are only asking for contributor forms from contributors of original material (such as module or manual section) and not from submitters of suggestions (via news,mail) or patches (via sourceforge). Correct? Seems sensible to me that contributing via a public suggestion box constitutes permission to use the suggestion. Terry J. Reedy ___ 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
[Python-Dev] Re: license issues with profiler.py and md5.h/md5c.c
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. How about this one: http://sourceforge.net/project/showfiles.php?group_id=42360 From an API standpoint, it's trivially different from the one currently in Python. From md5.c: /* Copyright (C) 1999, 2000, 2002 Aladdin Enterprises. All rights reserved. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. L. Peter Deutsch [EMAIL PROTECTED] */ /* $Id: md5.c,v 1.6 2002/04/13 19:20:28 lpd Exp $ */ /* Independent implementation of MD5 (RFC 1321). This code implements the MD5 Algorithm defined in RFC 1321, whose text is available at http://www.ietf.org/rfc/rfc1321.txt The code is derived from the text of the RFC, including the test suite (section A.5) but excluding the rest of Appendix A. It does not include any code or documentation that is identified in the RFC as being copyrighted. [etc.] -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ___ 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] Re: license issues with profiler.py and md5.h/md5c.c
On Sat, Feb 12, 2005, Terry Reedy wrote: > ""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> >> http://www.python.org/psf/contrib.html > > After reading this page and pages linked thereto, I get the impression that > you are only asking for contributor forms from contributors of original > material (such as module or manual section) and not from submitters of > suggestions (via news,mail) or patches (via sourceforge). Correct? Half-correct: patches constitute "work" and should also require a contrib agreement. But we're probably not going to press the point until we get contrib agreements from all CVS committers. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ 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
[Python-Dev] Re: Re: license issues with profiler.py and md5.h/md5c.c
"Aahz" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Sat, Feb 12, 2005, Terry Reedy wrote: >>> http://www.python.org/psf/contrib.html >> After reading this page and pages linked thereto, I get the impression >> that >> you are only asking for contributor forms from contributors of original >> material (such as module or manual section) and not from submitters of >> suggestions (via news,mail) or patches (via sourceforge). Correct? > Half-correct: patches constitute "work" and should also require a > contrib agreement. As I remember, my impression was based on the suggested procedure of first copywrite one's work and then license it under one of two acceptible "original licenses". This makes sense for a whole module, but hardly for most patches, to the point of being nonsense for a patch of one word, as some of mine have been (in text form, with the actual diff being prepared by the committer). This is not to deny that editing -- finding the exact place to insert or change a word is "work" -- but to say that it is work of a different sort from original authorship. So, if the lawyer thinks patches should also have a contrib agreement, then I strongly recommend a separate blanket agreement that covers all patches one ever contributes as one ongoing work. > But we're probably not going to press the point > until we get contrib agreements from all CVS committers. Even though I am not such, I would happily fill and fax a blanket patch agreement were that deemed to be helpful. Terry J. Reedy ___ 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
[Python-Dev] Jim Roskind
I contacted Jim Roskind re: the profiler code. i said: 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 you are desperate. If I were you, I'd wait for a license problem to emerge (which I don't believe will ever happen). Hope that helps, Jim David Ascher wrote on 2/11/2005, 8:57 PM: > Dear Jim -- > > David Ascher here, writing to you on behalf of th
Re: [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 unle
[Python-Dev] Re: license issues with profiler.py and md5.h/md5c.c
David Ascher wrote: FWIW, I agree. Personnally, I think that if Debian has a problem with the above, it's their problem to deal with, not Python's. The OSI may also have a problem with the license if they were to be made aware of it. See section 8 of the Open Source Definition: """8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. """ I'm not entirely sure if this affects the PSF's use of OSI's trademark. IANAL. TINLA. -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ___ 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
[Python-Dev] Re: OpenSSL sha module / license issues with md5.h/md5c.c
I've created an OpenSSL version of the sha module. trivial to modify to be a md5 module. Its a first version with cleanup to be done and such. being managed in the SF patch manager: https://sourceforge.net/tracker/?func=detail&aid=1121611&group_id=5470&atid=305470 enjoy. i'll do more cleanup and work on it soon. ___ 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
