Python 2.4 killing commercial Windows Python development ?

[Michael Kearns]

I've been using python to write a simple 'launcher' for one of our Java
applications for quite a while now. I recently updated it to use python
2.4, and all seemed well.

Today, one of my colleagues noted that on her machine the launcher would
complain it was missing a DLL - msvcr71.dll

However, there's a very grey area concerning the redistribution of said DLL.

If you've been keeping up with the dev list, and some other web
discussions, you'll see that this has cropped up several times, but with
no conclusion in a legal fashion other than 'investigate it on your own
legal terms'.

I'm now going to have step back to using 2.3 until this issue is solved,
but judging by the way the dev list discussion just faded, I get the
impression that it may be a long wait.

I can't see how any company (or individual) can distribute an
application written in python, and then 'frozen' (I used py2exe) in any
way if they rely on the python24.dll that ships as standard. This is
surely a step backwards in usability.

I have no idea concerning the issues of rebuilding a different version
of python24.dll to be linked against the common msvcr.dll or whatever,
or changing the 'freeze' applications to do some magic, but I can't
believe it should be down to the end user to jump through legal or
compilation hoops when they're trying to use the language.

Apologies if this seems more aggressive than I intended it to be - I'm
just frustrated at having to stop following my language of choice for
the foreseeable future so far as my work is concerned.

Michael.

 

[Thomas Heller]

I've been using python to write a simple 'launcher' for one of our
Java applications for quite a while now. I recently updated it to use
python 2.4, and all seemed well.

Today, one of my colleagues noted that on her machine the launcher
would complain it was missing a DLL - msvcr71.dll

However, there's a very grey area concerning the redistribution of said DLL.

If you've been keeping up with the dev list, and some other web
discussions, you'll see that this has cropped up several times, but
with no conclusion in a legal fashion other than 'investigate it on
your own legal terms'.

I'm now going to have step back to using 2.3 until this issue is
solved, but judging by the way the dev list discussion just faded, I
get the impression that it may be a long wait.

I can't see how any company (or individual) can distribute an
application written in python, and then 'frozen' (I used py2exe) in
any way if they rely on the python24.dll that ships as standard. This
is surely a step backwards in usability.

For commercial development, it should not be a problem to buy a license
for MSVC 7.1, which gives you the right to distribute msvcrt71.dll.

And maybe that's the reason that few people care about this issue?

Thomas

 

[Michael Kearns]

For commercial development, it should not be a problem to buy a license
for MSVC 7.1, which gives you the right to distribute msvcrt71.dll.

And maybe that's the reason that few people care about this issue?

Hi Thomas,

There are a few problems with this as I see it. In theory, the 'cost' of
MSVC 7.1 shouldn't be a problem for a big organisation. However, I
wouldn't expect to have to go and buy it purely because I'm developing
(perhaps) a shareware application using python - this isn't my case, but
I wasn't looking at it from just a big organisation perspective.

Also, I don't believe that just 'owning' MSVC 7.1 is enough. From
cursory glances at the various redist files, I would also have to ship
the EULA, and as an end-user (of python) I can't just redistribute the
files - perhaps I could write a place holder application in MSVC to
suggest that I was no longer an end-user, but this seems ridiculous as a
workaround.

There even seem to be 'exclude' clauses to redistribution concerning
open-source material, but IANAL and ran from the various paragraphs.

I would like to think that python would encourage as many folk as
possible to use the language wherever it fits best (and perhaps even
beyond) and yet this is going in the opposite direction.

Would it be so difficult for a 'no legalese attached' version to be
provided on windows, or at the very least, some kind of statement
regarding what is and isn't allowed ? There seems nothing within the
python distribution stating the redistribution rights of the dll
(correct me if I'm wrong) which already seems contrary to the MS
requirements.

As much as I'd like to continue using it, because of the vague legal
situation, I can't, and that's unfortunate.

Michael.

 

[Tim Peters]

[Michael Kearns]

...
Also, I don't believe that just 'owning' MSVC 7.1 is enough. From
cursory glances at the various redist files, I would also have to ship
the EULA, and as an end-user (of python) I can't just redistribute the
files - perhaps I could write a place holder application in MSVC to
suggest that I was no longer an end-user, but this seems ridiculous as a
workaround.

There even seem to be 'exclude' clauses to redistribution concerning
open-source material, but IANAL and ran from the various paragraphs.

I would like to think that python would encourage as many folk as
possible to use the language wherever it fits best (and perhaps even
beyond) and yet this is going in the opposite direction.

Would it be so difficult for a 'no legalese attached' version to be
provided on windows, or at the very least, some kind of statement
regarding what is and isn't allowed ?

I think it would be difficult. "We" (the Python developers) didn't
write Microsoft's license, have no special insight wrt it, and aren't
lawyers either. If you want legally binding clarifications or
exemptions, I think they have to come from Microsoft (it's their
license).

It would be cool if commercial users got together, pursued this with
MS, and shared what they learned. Of course it would also be cool if
someone with no commercial MS interests did so, but the chance of that
happening seems nil.

There seems nothing within the python distribution stating the redistribution
rights of the dll (correct me if I'm wrong) which already seems contrary to the
MS requirements.

That's possible too. MS hasn't complained to the PSF yet, but that's
no guarantee they won't.

As much as I'd like to continue using it, because of the vague legal
situation, I can't, and that's unfortunate.

Maybe the Python Business Forum could take this on? I don't know
whether they're still active, and their site isn't working today (at
least not for me):

http://www.python-in-business.org/

If someone(s) volunteered to do the work, it's also possible (not
certain) that the PSF would pay for lawyer time.

 

[Nemesis]

Mentre io pensavo ad una intro simpatica "Michael Kearns" scriveva:

I've been using python to write a simple 'launcher' for one of our Java
applications for quite a while now. I recently updated it to use python
2.4, and all seemed well.
Today, one of my colleagues noted that on her machine the launcher would
complain it was missing a DLL - msvcr71.dll

I have the same problem. But I have a doubt, does Python installer ship
this dll?
What happens if I try to install Python2.4 on a system wich doesn't have
the dll?

--
The complete lack of evidence is the surest sign that the conspiracy is
working.

|\ | |HomePage : http://nem01.altervista.org
| \|emesis |XPN (my nr): http://xpn.altervista.org

 

[Do Re Mi chel La Si Do]

Hi !

This DLL come also with MS-JVM engine, who is free. Therefore...

 

[Do Re Mi chel La Si Do]

And, also, with dotNET-framework

 

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

There are a few problems with this as I see it. In theory, the 'cost' of
MSVC 7.1 shouldn't be a problem for a big organisation. However, I
wouldn't expect to have to go and buy it purely because I'm developing
(perhaps) a shareware application using python - this isn't my case, but
I wasn't looking at it from just a big organisation perspective.

For developers that need msvcr71.dll on the target system which don't
have a license to distribute it, the solution is simple: they just need
to advise their users to install python-2.4.1.msi. This comes with
msvcr71.dll included.

Regards,
Martin

 

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

I have the same problem. But I have a doubt, does Python installer ship
this dll?

It sure does.

What happens if I try to install Python2.4 on a system wich doesn't have
the dll?

It will just work. Python installs the DLL if it is missing, and leaves
it alone (just incrementing the refcount) if it is present on the target
system.

Regards,
Martin

 

[Peter Hansen]

For developers that need msvcr71.dll on the target system which don't
have a license to distribute it, the solution is simple: they just need
to advise their users to install python-2.4.1.msi. This comes with
msvcr71.dll included.

I believe there are no restrictions on us redistributing
python-2.4.1.msi either, which would suggest that it
could simply be included in an installer package, and
perhaps the relevant DLLs could even be extracted from
the msi file without having to install it... I seem
to recall someone ;-) was making progress on an msi
package for Python which might be capable of this
too.

Of course then you'd need Python installed already in
order to install your application. On the other hand,
you could always include a copy of Python 2.3 as well,
and use that to extract the DLLs from the MSI.

Or other equally insane approaches ...

-Peter

 

[Michael Kearns]

For developers that need msvcr71.dll on the target system which don't
have a license to distribute it, the solution is simple: they just need
to advise their users to install python-2.4.1.msi. This comes with
msvcr71.dll included.

I understand this, and it's obviously a solution. Unfortunately it
defeats the whole point of me 'freezing' my code in the first place.

The main feature (for me) of the way I could use this, was to create a
simple Java launcher that didn't require the user to install anything
extra, or end up with a whole stack of unused data on their machine.

They would see a .exe file, a dll and a pyd, and then the actual
application files, and that was it. It may be fine for a 'knowledgeable'
user to install python etc., but not for everyone.

Michael.

 

[Michael Kearns]

Hi !

This DLL come also with MS-JVM engine, who is free. Therefore...

This is very true (and the .NET suggestion as well). However, why should
I require an end-user to install MS-JVM or the .NET framework, purely
for a simple little launcher application ?

The main application it launches is Java, but there's no way it would
run on the MS-JVM, and .NET just gives a load more technology that we
don't really need (and is a bigger install than the entire application).

Michael.

 

[Fredrik Lundh]

It will just work. Python installs the DLL if it is missing, and leaves
it alone (just incrementing the refcount) if it is present on the target
system.

installs it where? the MS docs seem to indicate that they want you to install
it in the program directory, rather than in a "shared" location:

http://support.microsoft.com/default.aspx?scid=kb;en-us;326922

</F>

 

[Jeff Epler]

I'm sorry that this is going to come out sounding like a flame, but it
seems to me that there today only a few technical problems remaining
with Python when built with mingw32.

If one of the people who has expressed such deep concern about this
"msvcr71.dll" problem would simply install the Free tools and start
putting patches on sourceforge, it's quite possible that for the next
2.4.x release the mingw32 "port" could be a first-rate one, and suitable
for the uses that the posters in this thread have mentioned.

Since mingw32 is Free (gpl and other licenses for tools, public domain
libraries and copyrighted headers with "no restrictions for programs"
built using the headers) anyone can install and use these tools and
mingw creates no new problems with distribution of the resulting binary,
whether the final product is Free or proprietary.

(Admittedly I don't know anything about whether "win32all" builds under
mingw32, and it's not clear whether binary compatibility with extensions
built by microsoft compilers is an easy goal either)

http://www.mingw.org/

Jeff

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

iD8DBQFCW9BaJd01MZaTXX0RAjSUAJ9rQ9iPncKGReearcIiAGaiE2pVCgCfbx39
eRPFXirdDedIlhyhXrs42RU=
=QgCW
-----END PGP SIGNATURE-----

 

[Terry Reedy]

I understand this, and it's obviously a solution. Unfortunately it defeats
the whole point of me 'freezing' my code in the first place.

The main feature (for me) of the way I could use this, was to create a
simple Java launcher that didn't require the user to install anything
extra, or end up with a whole stack of unused data on their machine.

I guess I don't understand some people's determination to not have users
install fully useable Python on their Windows machines. Doing so seems no
different to me than having to install (or upgrade) Shockwave, or Apple's
Quicksomething for Windows (not used so much anymore), or RealPlayer, or
the lastest upgrade for DirectX, or DivX, or a zip decoder, or any other
3rd party software, to run .xxx files or specialized .exe programs. (And I
left out the most direct analogy of a java system.)

In other words, it seems to me that most Windows users should be familiar
with the idea of having to install a player or platform to run something
built on top of that player or platform. Bundling a private Python
interpreter with every Python script is much like bundling a private
Shockwave player with every Schockwave script. I think most people would
prefer having one copy of each.

To put it another way, needing a Python interpreter to run .py files is no
different from, for instance, needing a movie player to run .mpg files, and
all Windows users are or need to become familiar with that general concept.

Also, I think it a bit 'anti-social' to hide usage of Python. If all
Python Windows programs ran with a normal, communally installed Python,
then users would gradually get the idea that having Python installed is
much like having Shockwave and other utility platforms installed, and that
is is part of a 'fully loaded' Windows system to have a .py player
installed.

If there is something about the default install of Python on Windows that
makes it less desireable or less easy than other platforms, then maybe that
can be fixed. To make installation easier, maybe someone could write a
small .exe that could be frozen with scripts or run with installers and
that would detect the presence/absence of the needed Python version and
offer an auto download and install if needed.

At least one thing in Python's favor is the lack of having to 'register'
before downloading (or after installation) and the ability to redistribute
the installer free and without special license.

Terry J. Reedy

 

[Thomas Heller]

[...]

Also, I think it a bit 'anti-social' to hide usage of Python. If all
Python Windows programs ran with a normal, communally installed Python,
then users would gradually get the idea that having Python installed is
much like having Shockwave and other utility platforms installed, and that
is is part of a 'fully loaded' Windows system to have a .py player
installed.

Isn't it a bit harsh to call this 'anti-social'?

If there is something about the default install of Python on Windows that
makes it less desireable or less easy than other platforms, then maybe that
can be fixed. To make installation easier, maybe someone could write a
small .exe that could be frozen with scripts or run with installers and
that would detect the presence/absence of the needed Python version and
offer an auto download and install if needed.

Sure. Someone.

At least one thing in Python's favor is the lack of having to 'register'
before downloading (or after installation) and the ability to redistribute
the installer free and without special license.

Thomas

 

[Dave Brueck]

I guess I don't understand some people's determination to not have users
install fully useable Python on their Windows machines. [snip]
To put it another way, needing a Python interpreter to run .py files is no
different from, for instance, needing a movie player to run .mpg files, and
all Windows users are or need to become familiar with that general concept.

Also, I think it a bit 'anti-social' to hide usage of Python. If all
Python Windows programs ran with a normal, communally installed Python,
then users would gradually get the idea that having Python installed is
much like having Shockwave and other utility platforms installed, and that
is is part of a 'fully loaded' Windows system to have a .py player
installed.

If there is something about the default install of Python on Windows that
makes it less desireable or less easy than other platforms, then maybe that
can be fixed. To make installation easier, maybe someone could write a
small .exe that could be frozen with scripts or run with installers and
that would detect the presence/absence of the needed Python version and
offer an auto download and install if needed.

I mostly agree with the sentiment, but it does break down a little in practice.
At least currently it does - like you said, this is fixable, but nobody has
signed up to fix it yet.

The main thing that's needed is a zero-input Python distribution - a Python
runtime, if you will - that (1) gets installed to a "good" place (2) does so
without asking the user to do anything, (3) can coexist with different versions
of the runtime, and (4) is easily detectable by applications wanting to use it.

One other minor component is a small launcher executable, because on Windows
it's non-trivial to find out which "python.exe" in the task manager is running
which Python script. Anyway, each app would have a small launcher that
bootstraps the actual Python script[1]. (Or, if there's some way to trick the
task manager into displaying something besides "python.exe", that'd work too)

In order to "fit" into the expectations of a typical Windows user, an
application installer needs the ability to check for the presence of a
particular version of the Python runtime, and then install it if it's not
present, and do so without asking the user to do anything.

With that much in place, a lot of the need for freezing Python apps goes away
(definitely not all of it, but a lot of it). Here's stuff that still needs to be
considered though:

1) A way for apps to specify their compatibility with different versions of the
runtime - "I work with pyrt2.3.3 through 2.4.1"

2) A way for apps to register their dependency on that runtime, so that if the
user uninstalls it, there is at least an indication of what programs might break.

3) (this is a nice-to-have, but not 100% required) A way to download additional
libraries once and use them for multiple programs, e.g. the installer could see
if ctypes is present, and if not, go get it. Later programs would take advantage
of it already being installed. Like I said, not a 100% requirement, and some of
the ongoing work with code CPAN-like code repositories would shoehorn into this.

4) The security implications, e.g. an innocent app installs pywin32 and enables
Python client-side scripting in Internet Explorer, and later this is used as a
big door for malicious users to use.

Most of these tasks don't require a lot of work; indeed this has been on my "one
of these days" lists for awhile. The main reasons it hasn't been done yet:

1) The code freezing tools like py2exe are *very* good and convenient
(especially since loading code from zip archives was added - even if you include
all of Python, it's only a few files on disk, and now they're all in the same
directory)

2) Storage space and download speeds continue to increase at a rate much faster
than the rate at which the size of Python is growing - a download of a few MB
isn't too bad these days, who cares if your app takes 4MB on disk, and so what
if it doesn't fit on a floppy, for example.

3) As soon as you get started on such a project, almost immediately you will be
overwhelmed with a desire to create a CPAN-like system while you're at it, at
which point your project's status will shift from "making good progress!" to "in
quagmire, developers MIA".

-Dave

[1] I built a hacky one of these launcher exe's for one project, and it was
fairly reusable for apps in the same vein. Basically, the exe would would look
to see what its name was, and then load a Python module of the same name. So if
you have MyGame.py, you'd just take the generic launcher.exe, copy it to the
same directory as your .py files, and rename it to MyGame.exe. On launch, it'd
load the interpreter, load MyGame.py, and pass it the command-line args.

 

[Thomas Heller]

I mostly agree with the sentiment, but it does break down a little in
practice. At least currently it does - like you said, this is fixable,
but nobody has signed up to fix it yet.

The main thing that's needed is a zero-input Python distribution - a
Python runtime, if you will - that (1) gets installed to a "good"
place (2) does so without asking the user to do anything, (3) can
coexist with different versions of the runtime, and (4) is easily
detectable by applications wanting to use it.

The effbot.exe platform (or how it's called) ?

One other minor component is a small launcher executable, because on
Windows it's non-trivial to find out which "python.exe" in the task
manager is running which Python script. Anyway, each app would have a
small launcher that bootstraps the actual Python script[1]. (Or, if
there's some way to trick the task manager into displaying something
besides "python.exe", that'd work too)

exemaker?

Thomas

 

[Dave Brueck]

The effbot.exe platform (or how it's called) ?

Yep - something along those lines, plus some docs for app developers. I don't
know if it installs all the stdlib, or just what effbot apps need, but I assume
the former.

One other minor component is a small launcher executable, because on
Windows it's non-trivial to find out which "python.exe" in the task
manager is running which Python script. Anyway, each app would have a
small launcher that bootstraps the actual Python script[1]. (Or, if
there's some way to trick the task manager into displaying something
besides "python.exe", that'd work too)

exemaker?

Something similar to that, yes. You'd need an option to generate a console
launcher or a Windows app launcher (maybe his latest version already has this?),
and a way to figure out which version of the runtime to use (rather than specify
the path ahead of time, you'd specify version requirements, and then at runtime
use registry entries to figure out where that runtime is), but the general idea
is the same.

-Dave

 

[Nemesis]

Mentre io pensavo ad una intro simpatica "Martin v. Löwis" scriveva:

It will just work. Python installs the DLL if it is missing, and leaves
it alone (just incrementing the refcount) if it is present on the target
system.

OK, so the python installer _does_ ship this dll. So also the win
installer has the redistribution problem, or does they pay for
redistributing msvcr71.dll?