RE: [Python-Dev] Is msvcr71.dll re-redistributable?

[Tony Meyer]

[Thanks for bringing this up, BTW, Thomas].

[Thomas Heller]
>> The 2.4 python.org installer installs msvcr71.dll on the 
>> target system. 
>>
>> If someone uses py2exe or a similar tool to create a frozen 
>> application, is he allowed to redistribute this msvcr71.dll
>> to other users together with his application or not, even if
>> he doesn't own MSVC?

[Vincent Wehren]
> According to the EULA,

Is that the EULA of MS VC++?

> you may distribute anything listed in redist.txt:

And, just to be clear, mscvr71.dll is in redist.txt?

> """2.2Redistributable Code-General.   Microsoft grants you a 
> nonexclusive, royalty-free right to reproduce and distribute 
> the object code form of any portion of the Software listed in
> REDIST.TXT ("Redistributable Code").  For general redistribution 
> requirements for Redistributable Code, see Section 3.1, below."""

Is it legit to redistribute an EULA?  If so, would you mind sending me a
copy of this (off-list)?

> So the right to distribute is coupled to the a) the EULA and b) 
> redist.txt. (As a side note, the Microsoft Visual C++ Toolkit 
> 2003 for example contains NO redistributables per redist.txt).

I'm not that familiar with the names of all these things.  Is the "Microsoft
Visual C++ Toolkit 2003" the free thing that you can get?

> In the case of not owning a compiler at all, chances seem pretty slim 
> you have any rights to distribute anything.

Well, I 'own' a copy of gcc, which is a compiler .

Can anyone here suggest a way to get around this?  As a specific example:
the SpamBayes distribution includes a py2exe binary, and it would be nice
(although not essential) to build this with 2.4.  However, at the moment my
name goes down as the release manager, and I don't have (AFAICT) a licence
to redistribute msvcr71.dl.

Should people in this situation just stick with 2.3 or buy a copy of a MS
compiler?

=Tony.Meyer

___
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] Is msvcr71.dll re-redistributable?

[Anders J. Munch]

>From Tony Meyer [mailto:[EMAIL PROTECTED]:

> Can anyone here suggest a way to get around this?  As a specific
> example: the SpamBayes distribution includes a py2exe binary, and it
> would be nice (although not essential) to build this with 2.4.
> However, at the moment my name goes down as the release manager, and
> I don't have (AFAICT) a licence to redistribute msvcr71.dl.

Instead of redistributing msvcr71.dll on your own volition, help
someone else distribute it:

1. John X. Programmer buys the product, agrees to the EULA and puts
   the DLL up for download, with the explicit and stated intent of
   distributing it to anyone who needs it.
2. You, being the nice person you are, decide to help John
   X. Programmer.  You do that by including msvcr71.dll in your
   software distribution.  After all, the users of your software needs
   it.  As you are merely aiding John X. Programmer in performing the
   redistribution that is within his rights to do, there is no need
   for anyone to be granted any additional rights, and specifically
   you do not need to agree to the EULA.

Unless the EULA contains specific language to forbid such multi-stage
open-ended redistribution, I'd say you can just re-redistribute away.

but-then-I-am-not-a-lawyer-ly y'rs, Anders
___
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] mimetypes and _winreg

[Thomas Heller]

Mike Brown <[EMAIL PROTECTED]> writes:

> Following up on this 12 Jun 2004 post...
>
> Garth wrote:
>> Thomas Heller wrote:
>> >Mike Brown <[EMAIL PROTECTED]> writes:
>> >>I thought it would be nice to try to improve the mimetypes module by 
>> >>having 
>> >>it, on Windows, query the Registry to get the mapping of filename 
>> >>extensions 
>> >>to media types, since the mimetypes code currently just blindly checks 
>> >>posix-specific paths for httpd-style mapping files. However, it seems that 
>> >>the 
>> >>way to get mappings from the Windows registry is excessively slow in 
>> >>Python.
>> >>
>> >>I'm told that the reason has to do with the limited subset of APIs that 
>> >>are 
>> >>exposed in the _winreg module. I think it is that EnumKey(key, index) is 
>> >>querying for the entire list of subkeys for the given key every time you 
>> >>call 
>> >>it. Or something. Whatever the situation is, the code I tried below is way 
>> >>slower than I think it ought to be.
>> >>
>> >>Does anyone have any suggestions (besides "write it in C")? Could _winreg 
>> >>possibly be improved to provide an iterator or better interface to get the 
>> >>subkeys? (or certain ones? There are a lot of keys under 
>> >>HKEY_CLASSES_ROOT, 
>> >>and I only need the ones that start with a period).
>> >
>> >See this post I made some time ago:
>> >
>> >
>> >>Should I file this as a feature request?
>> >
>> >If you still think it should be changed in the core, you should work on
>> >a patch.
>> >
>> I could file a patch if no one else is looking at it. The solution would 
>> be to use RegEnumKeyEx and remove RegQueryInfoKey. This loses
>> compatability with win16 which I guess is ok.
>> 
>> Garth
>
> I would say it looks like no one else was looking at it, and Garth apparently 
> didn't submit a patch. It's beyond my means to come up with a patch myself. 
> Would someone be willing to take a look at it?

There is a patch, but, as so often, work on it has stalled.
http://www.python.org/sf/977553

Thomas

___
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] Is msvcr71.dll re-redistributable?

[Stephen J. Turnbull]

> "Anders" == Anders J Munch <[EMAIL PROTECTED]> writes:

Anders> Unless the EULA contains specific language to forbid such
Anders> multi-stage open-ended redistribution, I'd say you can
Anders> just re-redistribute away.

Anders> but-then-I-am-not-a-lawyer-ly y'rs, Anders

I am not either, but in matters like this it works the other way
around: all rights not _explicitly_ granted are reserved.  Somebody
had better ask a real lawyer; in theory, you could be putting
downstream users who share with their friends at risk.


-- 
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN
   Ask not how you can "do" free software business;
  ask what your business can "do for" free software.
___
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] Is msvcr71.dll re-redistributable?

[Vincent Wehren]

Tony Meyer wrote:
[Thanks for bringing this up, BTW, Thomas].
[Thomas Heller]
[Vincent Wehren]
According to the EULA,

Is that the EULA of MS VC++?

The full text of the EULA for Visual C++ Toolkit 2003 can be found
at http://msdn.microsoft.com/visualc/vctoolkit2003/eula.aspx
For VS.NET:
http://proprietary.clendons.co.nz/licenses/eula/VisualStudiodotnetEnterpriseArchitect2002-eula.htm

you may distribute anything listed in redist.txt:

And, just to be clear, mscvr71.dll is in redist.txt?
Not in the free toolkit; in the $-version it must be.
I'm not that familiar with the names of all these things.  Is the "Microsoft
Visual C++ Toolkit 2003" the free thing that you can get?
Yep.
In the case of not owning a compiler at all, chances seem pretty slim 
you have any rights to distribute anything.

Well, I 'own' a copy of gcc, which is a compiler .
Can anyone here suggest a way to get around this?  As a specific example:
the SpamBayes distribution includes a py2exe binary, and it would be nice
(although not essential) to build this with 2.4.  However, at the moment my
name goes down as the release manager, and I don't have (AFAICT) a licence
to redistribute msvcr71.dl.
Okay: thinking about this for a bit longer: it is the Python interpreter 
that needs msvcr71.dll, right. You  need the python interpreter for 
py2exe. The distributor of Python is allowed to redistribute 
msvcr71.dll, and you are acting as re-distributor for the Python 
interpreter (to end users) and the EULA never even cares for/applies to 
the frozen binary...

--
Vincent Wehren
Should people in this situation just stick with 2.3 or buy a copy of a MS
compiler?
=Tony.Meyer

___
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] Is msvcr71.dll re-redistributable?

[Neil Hodgson]

Anders J. Munch:

> 1. John X. Programmer buys the product, agrees to the EULA and puts
>the DLL up for download, with the explicit and stated intent of
>distributing it to anyone who needs it.

   Disallowed in 3.1(a):
# you agree: ... to distribute the Redistributables only ... in 
# conjunction with and as a part of a software application 
# product developed by you that adds significant and primary 
# functionality to the Redistributables

> Unless the EULA contains specific language to forbid such multi-stage
> open-ended redistribution, I'd say you can just re-redistribute away.

   Lawyers think like lawyers much better than developers do.

   Neil
___
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] Is msvcr71.dll re-redistributable?

[Thomas Heller]

"Neil Hodgson" <[EMAIL PROTECTED]> writes:

> Anders J. Munch:
>
>> 1. John X. Programmer buys the product, agrees to the EULA and puts
>>the DLL up for download, with the explicit and stated intent of
>>distributing it to anyone who needs it.
>
>Disallowed in 3.1(a):
> # you agree: ... to distribute the Redistributables only ... in 
> # conjunction with and as a part of a software application 
> # product developed by you that adds significant and primary 
> # functionality to the Redistributables
>

All this pretty much subsumes what I was thinking.

The only question that remains is: why are there some sites like
http://www.dll-files.com/ which offer this and other MS dlls for
download?


For the spambayes binary, maybe there should be another person adding
the msvcr71.dll to the distribution that Tony builds?  Someone who has a
MSVC license, and also is developer on the spambayes project?

Thomas

___
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] Is msvcr71.dll re-redistributable?

[Tim Peters]

[Thomas Heller]
> ...
> For the spambayes binary, maybe there should be another person adding
> the msvcr71.dll to the distribution that Tony builds?  Someone who has a
> MSVC license, and also is developer on the spambayes project?

To the best of my knowledge, Tony is distributing my duly licensed
copy of msvcr71.dll with spambayes.  And so long as I remain totally
ignorant of what Tony actually does, that will remain my best
knowledge.  Win-win .
___
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 proposal: built in support for abstract methods

[Noam Raphael]

Hello,

I would like to suggest a new method decorator: abstractmethod. I'm
definitely not the only one who've thought about it, but I discussed
this on c.l.py, and came to think that it's a nice idea. An even
Pythonic!

This has nothing to do with type checking and adaptation - or, to be
more precise, it may be combined with them, but it will live happily
without them. I don't understand these issues a great deal.

What was my situations? I had to write a few classes, all with the
same interface but with a different implementation, that were meant to
work inside some infrastructure. The specific class that would be used
would be selected by what exactly the user wanted. Some methods of
these classes were exactly the same in all of the classes, so
naturally, I wrote a base class with an implementation of these
methods.

But then came the question: and what about the other methods? I wanted
to document that they should exist in all the classes of that family,
and that they should do XYZ; otherwise, they won't fit the
infrastructure. So I wrote something like:

def get_changed(self):
"""This method should return the changed keys since last call."""
raise NotImplementedError

But I wasn't happy about it. I thought that

@abstractmethod
def get_changed(self):
"""This methods should ..."""

would have been nicer. Why?

1. "Beautiful is better than ugly." - Who was talking here about
errors? I just wanted to say what the method should do!

2. "Explicit is better than implicit." - This is really the issue. I
*meant* to declare that a method should be implemented in subclasses,
and what it should do, but I *was* actually defining a method which
raises NotImplementedError when called with no arguments. I am used to
understanding NotImplementedError as "We should really implement this
some day, when we have the time", not as "In order to be a proud
subclass of BaseClass, you should implement this method".

3. "There should be one-- and preferably only one --obvious way to do
it." - I could have written this in a few other ways:

def get_changed(self):
"""This method should return the changed keys since last call.

PURE VIRTUAL.
"""

def get_changed(self):
"""This method should return the changed keys since last call."""
raise NotImplementedError, "get_changed is an abstract methods.
Subclasses of BaseClass should implement it."

What's good about the last example is that when the exception occurs,
it would be easier to find the problem. What's bad about it, is that
it's completely redundent, and very long to write.

Ok. Now another thing: I want classes that contain abstractmethods be
uninstantiable. One (and the main) reason is that instantiating that
class of mine doesn't make sense. It doesn't know how to do anything
useful, and doesn't represent any consistent object that you can have
instances of. The other reason is that it will help the programmer to
find out quickly methods he forgot to implement in his subclasses. You
may say that it suits "Errors should never pass silently."

The basic reason why I think this is fitting is that abstract classes
are something which is natural when creating class hierarchies;
usually, when I write a method, all subclasses must inherit it, or
implement another version with a compatible behaviour. Sometimes there
is no standard behaviour, so all subclasses must choose the second
option.

This concept is already in use in Python's standard library today!
"basestring" was created as the base class of "str" and "unicode".
What I'm proposing is just to make this possible also in code written
in Python.

George Sakkis has posted a very nice Python implementation of this:
http://groups-beta.google.com/group/comp.lang.python/msg/597e9ffa7b1f709b

To summarize, I think that abstract methods are simply not regular
functions, since by definition they don't specify actions, and so they
deserves an object of their own. And if it helps with testing the
subclasses - then why not?


What do you say?

Noam
___
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] Is msvcr71.dll re-redistributable?

[Tony Meyer]

[Thomas Heller]
>> For the spambayes binary, maybe there should be another 
>> person adding the msvcr71.dll to the distribution that Tony
>> builds?  Someone who has a MSVC license, and also is developer
>> on the spambayes project?

[Tim Peters]
> To the best of my knowledge, Tony is distributing my duly 
> licensed copy of msvcr71.dll with spambayes.  And so long as 
> I remain totally ignorant of what Tony actually does, that 
> will remain my best knowledge.  Win-win . 

That solves the specific SpamBayes problem.  It still seems like this is
somewhat of a PITA for people wanting to build frozen Windows apps with
Python 2.4, though.  OTOH, I can't personally think of anything (apart from
the it'll-never-fly go back to VC6 solution or the bound-to-be-terrible
static linking solution) that the Python developers can do about it.

(Well, there's that chap from Microsoft at PyCon, right?  How about one of
you convince him to convince Microsoft to give all Python developers a
licence to redistribute msvcr71.dll?  ).

BTW, this bit of the EULA isn't great:

""(iii) to distribute the Licensee Software containing the Redistributables
pursuant to an end user license agreement (which may be "break-the-seal",
"click-wrap" or signed), with terms no less protective than those contained
in this EULA;"""

The PSF licence is probably somewhat less protective than that one.  I
suppose the PSF licence really applies to the source, though, and not the
built binary.  Or something like that :)

(Users giving the software directly to someone else, rather than downloading
from the official site, is probably covered by:

"""You also agree not to permit further distribution of the Redistributables
by your end users except you may permit further redistribution of the
Redistributables by your distributors to your end-user customers if your
distributors only distribute the Redistributables in conjunction with, and
as part of, the Licensee Software and you and your distributors comply with
all other terms of this EULA."""

Where the users become our redistributors.)

=Tony.Meyer

___
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] redux: fractional seconds in strptime

[Brett C.]

Everyone went silent on this topic.  Does this mean people just stopped caring 
(which I doubt since I know Skip wants this bad enough to bring it up every so 
often)?  Was it the issue of symmetry with strftime?

I am willing to add this (albeit the simple way I proposed in my last email on 
this thread) but I obviously don't want to bother if no one wants it or likes 
my proposed solution.

-Brett
___
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] Is msvcr71.dll re-redistributable?

[Phillip J. Eby]

At 01:23 PM 2/3/05 +1300, Tony Meyer wrote:
(Users giving the software directly to someone else, rather than downloading
from the official site, is probably covered by:
"""You also agree not to permit further distribution of the Redistributables
by your end users except you may permit further redistribution of the
Redistributables by your distributors to your end-user customers if your
distributors only distribute the Redistributables in conjunction with, and
as part of, the Licensee Software and you and your distributors comply with
all other terms of this EULA."""
Where the users become our redistributors.)
Sounds like this puts all Python users in the clear, since Python is the 
Licensee Software in that case.  So, anybody can distribute msvcr71 as 
"part of" Python.

OTOH, the other wording sounds like Python itself has to have a click-wrap, 
tear-open, or signature EULA!  IOW, the EULA appears to prohibit free 
distribution of the runtime with a program that has no EULA.

So, in an amusing turn of events, the EULA actually appears to forbid the 
current offering of Python for Windows, since it does not have such a EULA.

This is a much bigger worry than the original question.  If we're actually 
allowed to distribute Python with the runtime at all, then py2exe and such 
are perfectly safe, since it's in conjunction with permitted 
redistribution.  If distribution of the runtime is not allowed, on the 
other hand, then use of MSVC 7 for Python becomes altogether impossible 
without adding some kind of click-wrap licensing scheme.

___
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] Is msvcr71.dll re-redistributable?

[Tony Meyer]

(I should point out the thread that starts here, too:



in case anyone isn't aware of it).

> Sounds like this puts all Python users in the clear, since 
> Python is the Licensee Software in that case.  So, anybody can
> distribute msvcr71 as "part of" Python.

I guess it would really take a lawyer (well, probably several) to say
whether distributing a frozen application is distributing Python or not.

> OTOH, the other wording sounds like Python itself has to have 
> a click-wrap, tear-open, or signature EULA!  IOW, the EULA
> appears to prohibit free distribution of the runtime with a
> program that has no EULA.
> 
> So, in an amusing turn of events, the EULA actually appears 
> to forbid the current offering of Python for Windows, since
> it does not have such a EULA.

I presume that adding a "click-wrap" EULA to the Python .msi would not be
difficult.  Lots of other .msi's have "click-wrap" licenses, so there must
be some sample code that can be used.  The license is already in the
distribution, it would just be displayed at an additional time.

The EULA has to be no less restrictive than the MSVC one (presumably only in
relation to the bits of MSVC that are being redistributed), so I guess a
section at the end of the PSF license that duplicates the relevant bits of
the MSVC one would work.  (Of course, IANAL).

=Tony.Meyer

___
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: Is msvcr71.dll re-redistributable?

[Terry Reedy]

"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> So, in an amusing turn of events, the EULA actually appears to forbid the 
> current offering of Python for Windows, since it does not have such a 
> EULA.

Except of course that MS gave Python developers several copies of its 
newest compiler specifically for the purpose of compiling the Windows 
distribution.

It would be nice to get a clear English statement from MS.  I have dealt 
with the legalese in property sales agreements, lease agreements, and 
normal software licenses, but the quoted EULA snippets are the most obscure 
by far.

Terry J. Reedy



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