profile.py has non-free license

[Debian Bug Importer]

Automatically imported from Debian bug report #293932 http://bugs.debian.org/293932

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #293932 http://bugs.debian.org/293932

[Debian Bug Importer (debzilla)]

Message-Id: <1107726549.20128.12.camel@localhost>
Date: Sun, 06 Feb 2005 21:49:08 +0000
From: Joe Wreschnig <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: profile.py has non-free license

--=-lGRS3BTQdgp0dqXm3+Vk
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Package: python
Severity: serious

The license for the Python profiler[0] does not allow it to be copied or
modified independently of other Python programs. This is a violation of
DFSG #3 (and also is just stupid). This bug affects likely every version
of Python in Debian (and that ever was in Debian) (and so IMO should not
hold up the sarge release).

Howeer, /usr/share/doc/python2.4/copyright does not include this
license. In fact, almost none of the licenses at
http://www.python.org/doc/current/lib/node822.html are included. At
least http://www.python.org/doc/current/lib/node826.html also looks
non-free.

[0]
http://www.python.org/doc/current/lib/node829.html
/usr/lib/python2.4/profile.py (or 2.3, or 2.2)

 Copyright 1994, by InfoSeek Corporation, all rights reserved.
 Written by James Roskind

 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.
--=20
Joe Wreschnig <email address hidden>

--=-lGRS3BTQdgp0dqXm3+Vk
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCBpDTTFkUq7Drx3cRAmfRAKC8A7Udt6f4s9gcMd8iSqm/rJmrNwCbBPu0
09YbbSe/cX93pIukW6sflwY=
=HYow
-----END PGP SIGNATURE-----

--=-lGRS3BTQdgp0dqXm3+Vk--

[Matthias Klose (doko-cs)]

[debian-legal, how do other packages handle the md5 stuff?]

Joe Wreschnig writes:
> Package: python
> Severity: serious
>
> The license for the Python profiler[0] does not allow it to be copied or
> modified independently of other Python programs. This is a violation of
> DFSG #3 (and also is just stupid). This bug affects likely every version
> of Python in Debian (and that ever was in Debian) (and so IMO should not
> hold up the sarge release).

ok, I'll address this upstream.

> Howeer, /usr/share/doc/python2.4/copyright does not include this
> license. In fact, almost none of the licenses at
> http://www.python.org/doc/current/lib/node822.html are included. At
> least http://www.python.org/doc/current/lib/node826.html also looks
> non-free.

will add the licenses to the 2.3 and 2.4 pacakges.

debian-legal, how do other packages handle the md5 stuff?

Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
rights reserved.

License to copy and use this software is granted provided that it
is identified as the "RSA Data Security, Inc. MD5 Message-Digest
Algorithm" in all material mentioning or referencing this software
or this function.

License is also granted to make and use derivative works provided
that such works are identified as "derived from the RSA Data
Security, Inc. MD5 Message-Digest Algorithm" in all material
mentioning or referencing the derived work.

RSA Data Security, Inc. makes no representations concerning either
the merchantability of this software or the suitability of this
software for any particular purpose. It is provided "as is"
without express or implied warranty of any kind.

These notices must be retained in any copies of any part of this
documentation and/or software.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 7 Feb 2005 13:27:55 +0100
From: Matthias Klose <email address hidden>
To: Joe Wreschnig <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#293932: profile.py has non-free license

[debian-legal, how do other packages handle the md5 stuff?]

Joe Wreschnig writes:
> Package: python
> Severity: serious
>
> The license for the Python profiler[0] does not allow it to be copied or
> modified independently of other Python programs. This is a violation of
> DFSG #3 (and also is just stupid). This bug affects likely every version
> of Python in Debian (and that ever was in Debian) (and so IMO should not
> hold up the sarge release).

ok, I'll address this upstream.

> Howeer, /usr/share/doc/python2.4/copyright does not include this
> license. In fact, almost none of the licenses at
> http://www.python.org/doc/current/lib/node822.html are included. At
> least http://www.python.org/doc/current/lib/node826.html also looks
> non-free.

will add the licenses to the 2.3 and 2.4 pacakges.

debian-legal, how do other packages handle the md5 stuff?

Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
rights reserved.

License to copy and use this software is granted provided that it
is identified as the "RSA Data Security, Inc. MD5 Message-Digest
Algorithm" in all material mentioning or referencing this software
or this function.

License is also granted to make and use derivative works provided
that such works are identified as "derived from the RSA Data
Security, Inc. MD5 Message-Digest Algorithm" in all material
mentioning or referencing the derived work.

RSA Data Security, Inc. makes no representations concerning either
the merchantability of this software or the suitability of this
software for any particular purpose. It is provided "as is"
without express or implied warranty of any kind.

These notices must be retained in any copies of any part of this
documentation and/or software.

[Andrew Suffield (asuffield)]

On Mon, Feb 07, 2005 at 01:27:55PM +0100, Matthias Klose wrote:
> debian-legal, how do other packages handle the md5 stuff?
>
> Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
> rights reserved.
>
> License to copy and use this software is granted provided that it
> is identified as the "RSA Data Security, Inc. MD5 Message-Digest
> Algorithm" in all material mentioning or referencing this software
> or this function.
>
> License is also granted to make and use derivative works provided
> that such works are identified as "derived from the RSA Data
> Security, Inc. MD5 Message-Digest Algorithm" in all material
> mentioning or referencing the derived work.
>
> RSA Data Security, Inc. makes no representations concerning either
> the merchantability of this software or the suitability of this
> software for any particular purpose. It is provided "as is"
> without express or implied warranty of any kind.
>
> These notices must be retained in any copies of any part of this
> documentation and/or software.

This is the copy of md5.c fished out of the specification. We've seen
it before.

There are other variations of md5.c, at least one of which has either
a BSD or an MIT license, I forget which. Look around, you should find
one easily enough. They're more or less equivalent, you may have to
fiddle the function names.

--
  .''`. ** Debian GNU/Linux ** | Andrew Suffield
 : :' : http://www.debian.org/ |
 `. `' |
   `- -><- |

[Matthias Klose (doko-cs)]

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."

The DFSG, http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg,
third paragraph state:

  "Derived Works
    The license must allow modifications and derived works, and must
    allow them to be distributed under the same terms as the license
    of the original software."

- Does somebody knows about the history of this license, why it is
  more restricted than the Python license?
- Is there a chance to change the license for these two modules
  (profile.py, pstats.py)?

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 7 Feb 2005 13:11:14 +0000
From: Andrew Suffield <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Re: Bug#293932: profile.py has non-free license

--VbJkn9YxBvnuCH5J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 07, 2005 at 01:27:55PM +0100, Matthias Klose wrote:
> debian-legal, how do other packages handle the md5 stuff?
>=20
> Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
> rights reserved.
>=20
> License to copy and use this software is granted provided that it
> is identified as the "RSA Data Security, Inc. MD5 Message-Digest
> Algorithm" in all material mentioning or referencing this software
> or this function.
>=20
> License is also granted to make and use derivative works provided
> that such works are identified as "derived from the RSA Data
> Security, Inc. MD5 Message-Digest Algorithm" in all material
> mentioning or referencing the derived work.
>=20
> RSA Data Security, Inc. makes no representations concerning either
> the merchantability of this software or the suitability of this
> software for any particular purpose. It is provided "as is"
> without express or implied warranty of any kind.
>=20
> These notices must be retained in any copies of any part of this
> documentation and/or software.

This is the copy of md5.c fished out of the specification. We've seen
it before.

There are other variations of md5.c, at least one of which has either
a BSD or an MIT license, I forget which. Look around, you should find
one easily enough. They're more or less equivalent, you may have to
fiddle the function names.

--=20
  .''`. ** Debian GNU/Linux ** | Andrew Suffield
 : :' : http://www.debian.org/ |
 `. `' |
   `- -><- |

--VbJkn9YxBvnuCH5J
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCB2jylpK98RSteX8RAuyoAJ9EgoVOorWgSpxMUwSOOtUjnfi12ACgkOej
FWkuwkQvDvPtoj01nes9qwc=
=skon
-----END PGP SIGNATURE-----

--VbJkn9YxBvnuCH5J--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 7 Feb 2005 14:36:32 +0100
From: Matthias Klose <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: license issues with profiler.py and md5.h/md5c.c

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."

The DFSG, http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg,
third paragraph state:

  "Derived Works
    The license must allow modifications and derived works, and must
    allow them to be distributed under the same terms as the license
    of the original software."

- Does somebody knows about the history of this license, why it is
  more restricted than the Python license?
- Is there a chance to change the license for these two modules
  (profile.py, pstats.py)?

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

[Steve McIntyre (steve-mcintyre)]

[ Gah, forgot to CC: the bug ]

doko wrote:
>[debian-legal, how do other packages handle the md5 stuff?]
>
>Joe Wreschnig writes:
>
>> Howeer, /usr/share/doc/python2.4/copyright does not include this
>> license. In fact, almost none of the licenses at
>> http://www.python.org/doc/current/lib/node822.html are included. At
>> least http://www.python.org/doc/current/lib/node826.html also looks
>> non-free.
>
>will add the licenses to the 2.3 and 2.4 pacakges.
>
>debian-legal, how do other packages handle the md5 stuff?

I've used the public domain implementation written by Colin Plumb, as
also used in dpkg. It's nigh-on a drop-in replacement.

--
Steve McIntyre, Cambridge, UK. <email address hidden>
"It's actually quite entertaining to watch ag129 prop his foot up on
 the desk so he can get a better aim." [ seen in ucam.chat ]

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 07 Feb 2005 14:39:47 +0000
From: Steve McIntyre <email address hidden>
To: <email address hidden>
Cc:
Subject: Re: Bug#293932: profile.py has non-free license

[ Gah, forgot to CC: the bug ]

doko wrote:
>[debian-legal, how do other packages handle the md5 stuff?]
>
>Joe Wreschnig writes:
>
>> Howeer, /usr/share/doc/python2.4/copyright does not include this
>> license. In fact, almost none of the licenses at
>> http://www.python.org/doc/current/lib/node822.html are included. At
>> least http://www.python.org/doc/current/lib/node826.html also looks
>> non-free.
>
>will add the licenses to the 2.3 and 2.4 pacakges.
>
>debian-legal, how do other packages handle the md5 stuff?

I've used the public domain implementation written by Colin Plumb, as
also used in dpkg. It's nigh-on a drop-in replacement.

--
Steve McIntyre, Cambridge, UK. <email address hidden>
"It's actually quite entertaining to watch ag129 prop his foot up on
 the desk so he can get a better aim." [ seen in ucam.chat ]

[Matthias Klose (doko)]

pending upload: use free implementation
needinfo/upstream profile license

[Gregory P. Smith (greg-electricrain)]

> 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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 8 Feb 2005 11:52:43 -0800
From: "Gregory P. Smith" <email address hidden>
To: Matthias Klose <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: [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

[Tim Peters (tim-peters)]

[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.

[Jeremy Hylton (jhylton-gmail)]

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 address hidden> 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
> <email address hidden>
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu
>

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 8 Feb 2005 15:37:50 -0500
From: Tim Peters <email address hidden>
To: Matthias Klose <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

[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.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 8 Feb 2005 15:52:29 -0500
From: Jeremy Hylton <email address hidden>
To: Tim Peters <email address hidden>
Cc: Matthias Klose <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: 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 address hidden> 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
> <email address hidden>
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu
>

[Matthias Klose (doko)]

Source: python2.3
Source-Version: 2.3.5-1

We believe that the bug you reported is fixed in the latest version of
python2.3, which is due to be installed in the Debian FTP archive:

idle-python2.3_2.3.5-1_all.deb
  to pool/main/p/python2.3/idle-python2.3_2.3.5-1_all.deb
python2.3-dev_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3-dev_2.3.5-1_i386.deb
python2.3-doc_2.3.5-1_all.deb
  to pool/main/p/python2.3/python2.3-doc_2.3.5-1_all.deb
python2.3-examples_2.3.5-1_all.deb
  to pool/main/p/python2.3/python2.3-examples_2.3.5-1_all.deb
python2.3-gdbm_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3-gdbm_2.3.5-1_i386.deb
python2.3-mpz_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3-mpz_2.3.5-1_i386.deb
python2.3-tk_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3-tk_2.3.5-1_i386.deb
python2.3_2.3.5-1.diff.gz
  to pool/main/p/python2.3/python2.3_2.3.5-1.diff.gz
python2.3_2.3.5-1.dsc
  to pool/main/p/python2.3/python2.3_2.3.5-1.dsc
python2.3_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3_2.3.5-1_i386.deb
python2.3_2.3.5.orig.tar.gz
  to pool/main/p/python2.3/python2.3_2.3.5.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Matthias Klose <email address hidden> (supplier of updated python2.3 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 8 Feb 2005 16:30:54 +0100
Source: python2.3
Binary: python2.3-doc idle-python2.3 python2.3-dev python2.3-examples python2.3-mpz python2.3 python2.3-gdbm python2.3-tk
Architecture: source all i386
Version: 2.3.5-1
Distribution: unstable
Urgency: medium
Maintainer: Matthias Klose <email address hidden>
Changed-By: Matthias Klose <email address hidden>
Description:
 idle-python2.3 - An IDE for Python (v2.3) using Tkinter
 python2.3 - An interactive high-level object-oriented language (version 2.3)
 python2.3-dev - Header files and a static library for Python (v2.3)
 python2.3-doc - Documentation for the high-level object-oriented language Python
 python2.3-examples - Examples for the Python language (v2.3)
 python2.3-gdbm - GNU dbm database support for Python (v2.3)
 python2.3-mpz - Multiple-precision arithmetic support for Python (v2.3)
 python2.3-tk - Tkinter - Writing Tk applications with Python (v2.3)
Closes: 293338 293932
Changes:
 python2.3 (2.3.5-1) unstable; urgency=medium
 .
   * Final 2.3.5 release.
   * Replace md5 implementation with one having a DFSG conforming license.
   * Remove the profile.py and pstats.py modules from the source package,
     not having a DFSG conforming license. The modules can be found in
     the python2.x-profile package in the non-free section. Closes: #293932.
   * Fix bug in copy.deep_copy (closes: #293338).
Files:
 80248fbcddbe7ee9ecc0313c47e2b528 1134 python o...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 09 Feb 2005 06:17:31 -0500
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: Bug#293932: fixed in python2.3 2.3.5-1

Source: python2.3
Source-Version: 2.3.5-1

We believe that the bug you reported is fixed in the latest version of
python2.3, which is due to be installed in the Debian FTP archive:

idle-python2.3_2.3.5-1_all.deb
  to pool/main/p/python2.3/idle-python2.3_2.3.5-1_all.deb
python2.3-dev_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3-dev_2.3.5-1_i386.deb
python2.3-doc_2.3.5-1_all.deb
  to pool/main/p/python2.3/python2.3-doc_2.3.5-1_all.deb
python2.3-examples_2.3.5-1_all.deb
  to pool/main/p/python2.3/python2.3-examples_2.3.5-1_all.deb
python2.3-gdbm_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3-gdbm_2.3.5-1_i386.deb
python2.3-mpz_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3-mpz_2.3.5-1_i386.deb
python2.3-tk_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3-tk_2.3.5-1_i386.deb
python2.3_2.3.5-1.diff.gz
  to pool/main/p/python2.3/python2.3_2.3.5-1.diff.gz
python2.3_2.3.5-1.dsc
  to pool/main/p/python2.3/python2.3_2.3.5-1.dsc
python2.3_2.3.5-1_i386.deb
  to pool/main/p/python2.3/python2.3_2.3.5-1_i386.deb
python2.3_2.3.5.orig.tar.gz
  to pool/main/p/python2.3/python2.3_2.3.5.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Matthias Klose <email address hidden> (supplier of updated python2.3 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 8 Feb 2005 16:30:54 +0100
Source: python2.3
Binary: python2.3-doc idle-python2.3 python2.3-dev python2.3-examples python2.3-mpz python2.3 python2.3-gdbm python2.3-tk
Architecture: source all i386
Version: 2.3.5-1
Distribution: unstable
Urgency: medium
Maintainer: Matthias Klose <email address hidden>
Changed-By: Matthias Klose <email address hidden>
Description:
 idle-python2.3 - An IDE for Python (v2.3) using Tkinter
 python2.3 - An interactive high-level object-oriented language (version 2.3)
 python2.3-dev - Header files and a static library for Python (v2.3)
 python2.3-doc - Documentation for the high-level object-oriented language Python
 python2.3-examples - Examples for the Python language (v2.3)
 python2.3-gdbm - GNU dbm database support for Python (v2.3)
 python2.3-mpz - Multiple-precision arithmetic support for Python (v2.3)
 python2.3-tk - Tkinter - Writing Tk applications with Python (v2.3)
Closes: 293338 293932
Changes:
 python2.3 (2.3.5-1) unstable; urgency=medium
 .
   * Final 2.3.5 release.
   * Replace md5 implementation with one having a DFSG conforming license.
   * Remove the profile.py and pstats.py modules from the source package,
     not having a DFSG conforming license. ...

[Matthias Klose (doko)]

fixed in all python2.x packages, separated out into the non-free
python2.x-profiler packages

[Donovan Baarda (abo-minkirri)]

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 address hidden>
http://minkirri.apana.org.au/~abo/

[Bob Ippolito (etrepum)]

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

[Donovan Baarda (abo-minkirri)]

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 address hidden>
http://minkirri.apana.org.au/~abo/

[Debian Bug Importer (debzilla)]

Message-Id: <1108088147.3753.51.camel@schizo>
Date: Fri, 11 Feb 2005 13:15:47 +1100
From: Donovan Baarda <email address hidden>
To: "Gregory P. Smith" <email address hidden>
Cc: Matthias Klose <email address hidden>, <email address hidden>,
 Python Developers List <email address hidden>
Subject: 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 address hidden>
http://minkirri.apana.org.au/~abo/

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 10 Feb 2005 21:30:59 -0500
From: Bob Ippolito <email address hidden>
To: Donovan Baarda <email address hidden>
Cc: "Gregory P. Smith" <email address hidden>, Python Developers List <email address hidden>,
 Matthias Klose <email address hidden>, <email address hidden>
Subject: 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

[Debian Bug Importer (debzilla)]

Message-Id: <1108090248.3753.53.camel@schizo>
Date: Fri, 11 Feb 2005 13:50:48 +1100
From: Donovan Baarda <email address hidden>
To: Bob Ippolito <email address hidden>
Cc: "Gregory P. Smith" <email address hidden>, Python Developers List <email address hidden>,
 Matthias Klose <email address hidden>, <email address hidden>
Subject: 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 address hidden>
http://minkirri.apana.org.au/~abo/

[Bob Ippolito (etrepum)]

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

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 10 Feb 2005 23:13:55 -0500
From: Bob Ippolito <email address hidden>
To: Donovan Baarda <email address hidden>
Cc: "Gregory P. Smith" <email address hidden>, Python Developers List <email address hidden>,
 Matthias Klose <email address hidden>, <email address hidden>
Subject: 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

[Donovan Baarda (abo-minkirri)]

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 address hidden>
http://minkirri.apana.org.au/~abo/

[Donovan Baarda (abo-minkirri)]

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 address hidden>
http://minkirri.apana.org.au/~abo/

[Debian Bug Importer (debzilla)]

Message-Id: <1108102539.3753.87.camel@schizo>
Date: Fri, 11 Feb 2005 17:15:39 +1100
From: Donovan Baarda <email address hidden>
To: Bob Ippolito <email address hidden>
Cc: "Gregory P. Smith" <email address hidden>, Python Developers List <email address hidden>,
 Matthias Klose <email address hidden>, <email address hidden>
Subject: 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 address hidden>
http://minkirri.apana.org.au/~abo/

[Debian Bug Importer (debzilla)]

Message-Id: <1108104740.3753.91.camel@schizo>
Date: Fri, 11 Feb 2005 17:52:20 +1100
From: Donovan Baarda <email address hidden>
To: Bob Ippolito <email address hidden>
Cc: <email address hidden>, Matthias Klose <email address hidden>,
 Python Developers List <email address hidden>
Subject: Re: [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 address hidden>
http://minkirri.apana.org.au/~abo/

[Matthias Klose (doko-cs)]

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.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 11 Feb 2005 12:55:02 +0100
From: Matthias Klose <email address hidden>
To: Donovan Baarda <email address hidden>
Cc: <email address hidden>, Python Developers List <email address hidden>
Subject: 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.

[Jeremy Hylton (jhylton-gmail)]

On Fri, 11 Feb 2005 12:55:02 +0100, Matthias Klose <email address hidden> 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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 11 Feb 2005 07:35:18 -0500
From: Jeremy Hylton <email address hidden>
To: Matthias Klose <email address hidden>
Cc: Donovan Baarda <email address hidden>, <email address hidden>,
 Python Developers List <email address hidden>
Subject: 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 address hidden> 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

[Gregory P. Smith (greg-electricrain)]

> 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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 11 Feb 2005 09:51:18 -0800
From: "Gregory P. Smith" <email address hidden>
To: Donovan Baarda <email address hidden>
Cc: Bob Ippolito <email address hidden>, "Gregory P. Smith" <email address hidden>,
 Python Developers List <email address hidden>,
 Matthias Klose <email address hidden>, <email address hidden>
Subject: 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

[Michael Chermside (mcherm)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 11 Feb 2005 12:03:29 -0800
From: Michael Chermside <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: 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

[Tim Peters (tim-peters)]

[Jeremy Hylton]
>> 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

[Michael Chermside]
> 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.

The article Jeremy pointed at was written by the Python Software
Foundation's occasional legal counsel, and he disagrees. While I
would love to believe that copyright law isn't this bizarre, I can't
recommend going against the best legal advice the PSF was willing to
pay for <wink -- but Larry is widely recognized as a bona fide expert
in IP law, and has helped the PSF a lot>.

Note that Creative Commons doesn't recommend that you do either; from their FAQ:

   Can I use a Creative Commons license for software?

   In theory, yes, but it is not in your best interest. We strongly
encourage you to
   use one of the very good software licenses available today. (The
Free Software
   Foundation and the Open Source Initiative stand out as resources for such
   licenses.)

> 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).

So would I, but according to Larry there isn't such a thing (excepting
software written by the US Government; and for other software you
might be thinking about today, maybe in about a century if the author
lets their copyright lapse).

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.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 11 Feb 2005 15:46:00 -0500
From: Tim Peters <email address hidden>
To: Michael Chermside <email address hidden>
Cc: <email address hidden>, <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

[Jeremy Hylton]
>> 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

[Michael Chermside]
> 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.

The article Jeremy pointed at was written by the Python Software
Foundation's occasional legal counsel, and he disagrees. While I
would love to believe that copyright law isn't this bizarre, I can't
recommend going against the best legal advice the PSF was willing to
pay for <wink -- but Larry is widely recognized as a bona fide expert
in IP law, and has helped the PSF a lot>.

Note that Creative Commons doesn't recommend that you do either; from their FAQ:

   Can I use a Creative Commons license for software?

   In theory, yes, but it is not in your best interest. We strongly
encourage you to
   use one of the very good software licenses available today. (The
Free Software
   Foundation and the Open Source Initiative stand out as resources for such
   licenses.)

> 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).

So would I, but according to Larry there isn't such a thing (excepting
software written by the US Government; and for other software you
might be thinking about today, maybe in about a century if the author
lets their copyright lapse).

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.

[PJE (pje-telecommunity)]

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. Therefor...

[Donovan Baarda (abo-minkirri)]

G'day again,

From: "Gregory P. Smith" <email address hidden>
> > 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 Baarda http://minkirri.apana.org.au/~abo/
----------------------------------------------------------------

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Fri, 11 Feb 2005 17:59:33 -0500
From: "Phillip J. Eby" <email address hidden>
To: Tim Peters <email address hidden>,
 Michael Chermside <email address hidden>
Cc: <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: 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 copy...

[Debian Bug Importer (debzilla)]

Message-ID: <00c701c5108e$f3d0b930$<email address hidden>>
Date: Sat, 12 Feb 2005 10:11:01 +1100
From: "Donovan Baarda" <email address hidden>
To: "Gregory P. Smith" <email address hidden>
Cc: "Bob Ippolito" <email address hidden>, "Gregory P. Smith" <email address hidden>,
 "Python Developers List" <email address hidden>,
 "Matthias Klose" <email address hidden>, <email address hidden>
Subject: Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

G'day again,

From: "Gregory P. Smith" <email address hidden>
> > 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 Baarda http://minkirri.apana.org.au/~abo/
----------------------------------------------------------------

[Martin v. Löwis (martin-v)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2005 00:57:40 +0100
From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[e-mail]>
To: "Phillip J. Eby" <email address hidden>
CC: Tim Peters <email address hidden>, Michael Chermside <email address hidden>,
 <email address hidden>, <email address hidden>, <email address hidden>
Subject: 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

[Bob Ippolito (etrepum)]

On Feb 11, 2005, at 6:11 PM, Donovan Baarda wrote:

> G'day again,
>
> From: "Gregory P. Smith" <email address hidden>
>>> 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

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Fri, 11 Feb 2005 20:38:18 -0500
From: Bob Ippolito <email address hidden>
To: "Donovan Baarda" <email address hidden>
Cc: "Matthias Klose" <email address hidden>, "Gregory P. Smith" <email address hidden>,
 <email address hidden>, "Python Developers List" <email address hidden>
Subject: 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 address hidden>
>>> 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

[Donovan Baarda (abo-minkirri)]

G'day,

From: "Bob Ippolito" <email address hidden>
> 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 Baarda http://minkirri.apana.org.au/~abo/
----------------------------------------------------------------

[Debian Bug Importer (debzilla)]

Message-ID: <013501c510ae$2abd7360$<email address hidden>>
Date: Sat, 12 Feb 2005 13:54:27 +1100
From: "Donovan Baarda" <email address hidden>
To: "Bob Ippolito" <email address hidden>
Cc: "Matthias Klose" <email address hidden>,
 "Gregory P. Smith" <email address hidden>, <email address hidden>,
 "Python Developers List" <email address hidden>
Subject: Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

G'day,

From: "Bob Ippolito" <email address hidden>
> 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 Baarda http://minkirri.apana.org.au/~abo/
----------------------------------------------------------------

[David-ascher (david-ascher)]

On Tue, 8 Feb 2005 15:52:29 -0500, Jeremy Hylton <email address hidden> 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
CONTRAC...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 12 Feb 2005 13:45:54 -0800
From: David Ascher <email address hidden>
To: <email address hidden>
Cc: Tim Peters <email address hidden>, <email address hidden>,
 Matthias Klose <email address hidden>, <email address hidden>
Subject: 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 address hidden> 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. =20
This is what I found on the web for it:

    Copyright =A9 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 in...

[Gregory P. Smith (greg-electricrain)]

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.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 12 Feb 2005 17:35:35 -0800
From: "Gregory P. Smith" <email address hidden>
To: Donovan Baarda <email address hidden>
Cc: Bob Ippolito <email address hidden>, Matthias Klose <email address hidden>,
 "Gregory P. Smith" <email address hidden>, <email address hidden>,
 Python Developers List <email address hidden>
Subject: 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.

[Donovan Baarda (abo-minkirri)]

On Sat, 2005-02-12 at 17:35 -0800, Gregory P. Smith wrote:
> 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.

Hmmm. I see the patch entry, but it seems to be missing the actual
patch.

Did you code this from scratch, or did you base it on the current
md5module.c? Is it using the openssl sha interface, or the higher level
EVP interface?

The reason I ask is it would be pretty trivial to modify md5module.c to
use the openssl API for any digest, and would be less risk than
fresh-coding one.

--
Donovan Baarda <email address hidden>
http://minkirri.apana.org.au/~abo/

[Gregory P. Smith (greg-electricrain)]

On Mon, Feb 14, 2005 at 11:02:23AM +1100, Donovan Baarda wrote:
> On Sat, 2005-02-12 at 17:35 -0800, Gregory P. Smith wrote:
> > 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.
>
> Hmmm. I see the patch entry, but it seems to be missing the actual
> patch.
>
> Did you code this from scratch, or did you base it on the current
> md5module.c? Is it using the openssl sha interface, or the higher level
> EVP interface?
>
> The reason I ask is it would be pretty trivial to modify md5module.c to
> use the openssl API for any digest, and would be less risk than
> fresh-coding one.

Ugh. Sourceforge ignored it on the patch submission. i've attached
it properly now.

This initial version is derived from shamodule.c which does not have
any license issues. it is currently only meant as an example of how
easy it is to use the openssl hashing interface.

I'm taking it an turning it into a generic openssl hash wrapper
that'll do md5 sha1 and anything else.

-g

[Debian Bug Importer (debzilla)]

Message-Id: <1108339344.3768.24.camel@schizo>
Date: Mon, 14 Feb 2005 11:02:23 +1100
From: Donovan Baarda <email address hidden>
To: "Gregory P. Smith" <email address hidden>
Cc: Bob Ippolito <email address hidden>, Matthias Klose <email address hidden>, <email address hidden>,
 Python Developers List <email address hidden>
Subject: Re: OpenSSL sha module / license issues with md5.h/md5c.c

On Sat, 2005-02-12 at 17:35 -0800, Gregory P. Smith wrote:
> 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.

Hmmm. I see the patch entry, but it seems to be missing the actual
patch.

Did you code this from scratch, or did you base it on the current
md5module.c? Is it using the openssl sha interface, or the higher level
EVP interface?

The reason I ask is it would be pretty trivial to modify md5module.c to
use the openssl API for any digest, and would be less risk than
fresh-coding one.

--
Donovan Baarda <email address hidden>
http://minkirri.apana.org.au/~abo/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 13 Feb 2005 16:21:54 -0800
From: "Gregory P. Smith" <email address hidden>
To: Donovan Baarda <email address hidden>
Cc: "Gregory P. Smith" <email address hidden>, Bob Ippolito <email address hidden>,
 Matthias Klose <email address hidden>, <email address hidden>,
 Python Developers List <email address hidden>
Subject: Re: OpenSSL sha module / license issues with md5.h/md5c.c

On Mon, Feb 14, 2005 at 11:02:23AM +1100, Donovan Baarda wrote:
> On Sat, 2005-02-12 at 17:35 -0800, Gregory P. Smith wrote:
> > 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.
>
> Hmmm. I see the patch entry, but it seems to be missing the actual
> patch.
>
> Did you code this from scratch, or did you base it on the current
> md5module.c? Is it using the openssl sha interface, or the higher level
> EVP interface?
>
> The reason I ask is it would be pretty trivial to modify md5module.c to
> use the openssl API for any digest, and would be less risk than
> fresh-coding one.

Ugh. Sourceforge ignored it on the patch submission. i've attached
it properly now.

This initial version is derived from shamodule.c which does not have
any license issues. it is currently only meant as an example of how
easy it is to use the openssl hashing interface.

I'm taking it an turning it into a generic openssl hash wrapper
that'll do md5 sha1 and anything else.

-g