python+py2exe+pygame licensing ?

Andrea Griffini agriff at
Mon Jun 14 08:23:18 CEST 2004

On Sat, 12 Jun 2004 18:11:01 -0400, "Chris S."
<chrisks at> wrote:

>Since Python byte-code can be decompiled, I'm not sure how 
>"closed-source" you could make a Python program.

Legally closed source is one thing, technically closed
source is another. Anyway I was wondering that if there
is anything in the license that *forces* me to put an
easily re-usable source code the impression on the
management could be quite worse.

If I can distribute a copyrighted compiled-only version,
and take you to a court if I discover that you used
part of it then things are different. The fact that
there are decompilers around that can take the compiled
version a produce a very good source version is not central.
I've found even someone that sells this as a *service* on
the net (it's not for cracking or illegal inspection,
it's in case you lost the source code of your programs...
of course :-) ).

That anthing of this is important from a pratical point
of view is quite questionable; but I'm talking about
explaining to management that python is an interesting
alternative for more than internal prototyping...

>However, legally I see no reason why you couldn't try.
>The Python license puts no restrictions on closed sourcing.
>Py2exe and psyco are covered by the MIT license, which also
>doesn't restriction proprietary source.

I suppose then that I'll only need to copy a few license
text files in the final directory...

>Pygame is licensed under the LGPL, so you the only
>source you'd have to release are the modifications you'd
>make to pygame itself, not the code utilizing the
>pygame API.

This is something that always puzzled me. If I include
an LGPL'ed part and a new version of that part is not
100% interface-compatible with an old one (as sometimes
happens with specific libraries), am I forced to allow
my clients to adapt to the new version ? Am I forced
to provide upgrades forever ?

When I first read the LGPL, my impression was that it
was suited more for incredibly stable libraries (at
least stable at the interface level). For example the
standard C library...

But english legalese is not my natural language... :-)


More information about the Python-list mailing list