Re: [Python-Dev] Re: Re: license issues with profiler.py and md5.h/md5c.c

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Terry Reedy wrote:
As I remember, my impression was based on the suggested procedure of first 
copywrite one's work and then license it under one of two acceptible 
"original licenses".  This makes sense for a whole module, but hardly for 
most patches, to the point of being nonsense for a patch of one word, as 
some of mine have been (in text form, with the actual diff being prepared 
by the committer).
To my understanding, there is no way to "copyright one's work" - in the
terminology of Larry Rosen (and I guess U.S. copyright law), "copyright
subsists". I.e. the creator of some work has copyright, whether he wants
it or not.
Now, the question is, what precisely constitutes "work"? To my
understanding, modifying an existing work creates derivative work;
he who creates the derivative work first needs a license to do
so, and then owns the title of the derivative work.
There is, of course, the issue of trivial changes - "nobody could have
it done differently". However, I understand that the bar for trivial
changes is very, very low; I understand that even putting a comment into
the change indicating what the change was already makes this original
work. Nobody is obliged to phrase the comment in precisely the same way,
so this specific wording of the comment is original work of the
contributor, who needs to license the change to us.
So, if the lawyer thinks patches should also have a contrib agreement, then 
I strongly recommend a separate blanket agreement that covers all patches 
one ever contributes as one ongoing work.
Our contributor's form is such a blanket agreement. You fill it out
once, and then you indicate, in each patch, that this patch falls under
the agreement you sent in earlier.
Even though I am not such, I would happily fill and fax a blanket patch 
agreement were that deemed to be helpful.
When we have sufficient coverage from committers, I will move on to
people in Misc/ACKS. You can just go ahead and send in the form
right away.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: OpenSSL sha module / license issues with md5.h/md5c.c

[Donovan Baarda]

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

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

[Donovan Baarda]

G'day,

On Sat, 2005-02-12 at 13:04 -0800, Gregory P. Smith wrote:
> On Sat, Feb 12, 2005 at 08:37:21AM -0500, A.M. Kuchling wrote:
> > On Sat, Feb 12, 2005 at 01:54:27PM +1100, Donovan Baarda wrote:
> > > Are there any potential problems with making the md5sum module 
> > > availability
> > > "optional" in the same way as this?
> > 
> > The md5 module has been a standard module for a long time; making it
> > optional in the next version of Python isn't possible.  We'd have to
> > require OpenSSL to compile Python.
> > 
> > I'm happy to replace the MD5 and/or SHA implementations with other
> > code, provided other code with a suitable license can be found.
> > 
> 
> agreed.  it can not be made optional.  What I'd prefer (and will do if
> i find the time) is to have the md5 and sha1 module use OpenSSLs
> implementations when available.  Falling back to their built in ones
> when openssl isn't present.  That way its always there but uses the
> much faster optimized openssl algorithms when they exist.

So we need a fallback md5 implementation for when openssl is not
available.

The RSA implementation is not usable because it has an unsuitable
license. Looking at this licence again, I'm not sure what the problem
is. It allows you to freely modify, distribute, etc, with the only limit
you must retain the RSA licence blurb.

The libmd implementation cannot be used because the author tried to give
it away unconditionally, and the lawyers say you can't. (dumb! dumb!
dumb! someone needs to figure out a way to systematically get around
this kind of stupidity, perhaps have someone in a less legally stupid
country claim and re-license free code).

The libmd5-rfc sourceforge project implementation
 looks OK. It needs to be
modified to have an API identical to openssl (rename
structures/functions). Then setup.py needs to be modified to use openssl
if available, or fallback to the provided libmd5-rfc implementation.

The SHA module is a bit different... it includes a built in SHA
implementation. It might pay to strip out the implementation and give it
an openssl-like API, then make shamodule.c a use it, or openssl if
available. Greg Smith might have already done much of this...

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: OpenSSL sha module / license issues with md5.h/md5c.c

[Gregory P. Smith]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] A hybrid C & Python implementation for itertools

[Nick Coghlan]

I can't really imagine Raymond liking this idea, and I have a feeling the idea 
has been shot down before. However, I can't persuade Google to tell me anything 
about such an occasion, so here goes anyway. . .

The utilities in the itertools module can easily be composed to provide 
additional useful functionality (e.g. the itertools recipes given in the 
documentation [1]).

However, having to recode these every time you need them, or arranging access to 
a utility module can be a pain for application programming in some corporate 
environments [2]. The lack of builtin support also leads to many variations on a 
theme, only some of which actually work properly, or which work, but in subtly 
different ways [3]. On the other hand, it really isn't worth the effort to code 
these algorithms in C for the current itertools module.

If itertools was a hybrid module, the handy 3-4 liners could go in the Python 
section, with the heavy lifting done by the underlying C module. The Python 
equivalents to the current C code could also be placed in the hybrid module (as 
happens with some of the other hybrid modules in the library).

An alternative approach is based on an idea from Alex Martelli [4]. As Alex 
points out, itertools is currently more about *creating* iterators than it is 
about consuming them (the only function desription that doesn't start with 'Make 
an iterator' is itertools.tee and that starts with 'Return n independent 
iterators'). Alex's idea would involve adding a module with a new name that is 
focused on *consuming* iterators (IOW, extending the available standard 
accumulators beyond the existing min(), max() and sum() without further 
populating the builtins).

The downside of the latter proposal is that the recipes in the itertools 
documentation relate both to producing *and* consuming iterators, so a new 
module would leave the question of where to put the handy iterator producers.

Regards,
Nick.
[1] http://www.python.org/dev/doc/devel/lib/itertools-recipes.html
[2] http://mail.python.org/pipermail/python-list/2005-February/266310.html
[3] http://mail.python.org/pipermail/python-list/2005-February/266311.html
[4] http://groups-beta.google.com/group/comp.lang.python/msg/a76b4c2caf6c435c
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A hybrid C & Python implementation for itertools

[Raymond Hettinger]

[Nick Coghlan]
> If itertools was a hybrid module, the handy 3-4 liners could go in the Python
> section, with the heavy lifting done by the underlying C module. The Python
> equivalents to the current C code could also be placed in the hybrid module 
> (as
> happens with some of the other hybrid modules in the library).

Both of those ideas likely reflect the future direction of itertools.

FWIW, the historical reasons for keeping the derived tools in the docs were:

* Not casting them in stone too early so they could be updated and refined at 
will.

* They had more value as a teaching tool (showing how basic tools could be 
combined) than as stand-alone tools.

* Adding more tools makes the whole toolset harder to use.

* When an itertool solution is not immediately obvious, then a generator 
solution is likely to be easier to write and more
understandable. Your two alternate partitioning recipes provide an excellent 
case in point.

* Several of the derived tools do not arise often in practice.  For example, 
I've never used tabulate(), nth(), pairwise(), or
repeatfunc().



> Alex's idea would involve adding a module with a new name that is
> focused on *consuming* iterators (IOW, extending the available standard
> accumulators beyond the existing min(), max() and sum() without further
> populating the builtins).

That would be nice.  From the existing itertool recipes, good candidates would 
include take(), all(), any(), no(), and quantify().


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com