python+py2exe+pygame licensing ?

[Andrea Griffini]

Just a quick shoot... can I produce a "closed source"
program using "core" python, pygame (and eventually psyco),
packaging it by using py2exe and a custom installer ?

A clear yes/no answer is something I'll be asked about
when proposing python as an interesting alternative.

If the answer is "no" (as I fear) what's the minimum
of "opening" that must be done ?

If the problem is pygame I may decide to rewrite the
little part of it that I need as a python extension...

Andrea

 

[Chris S.]

Just a quick shoot... can I produce a "closed source"
program using "core" python, pygame (and eventually psyco),
packaging it by using py2exe and a custom installer ?

A clear yes/no answer is something I'll be asked about
when proposing python as an interesting alternative.

If the answer is "no" (as I fear) what's the minimum
of "opening" that must be done ?

If the problem is pygame I may decide to rewrite the
little part of it that I need as a python extension...

Andrea

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

 

[Andrea Griffini]

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

Andrea

 

[Peter Hansen]

Just a quick shoot... can I produce a "closed source"
program using "core" python, pygame (and eventually psyco),
packaging it by using py2exe and a custom installer ?

A clear yes/no answer is something I'll be asked about
when proposing python as an interesting alternative.

You'll get safe answers about this only if you hire a
lawyer. And clear ones only if you hire a bad lawyer. <wink>

On the other hand, you might improve the quality of the
responses if you would take the time to include links
to the relevant licenses for each of the components that
interest you. At least that way you aren't expecting
those people who might respond to duplicate all the legwork
that you should already have done...

-Peter

 

[David Fraser]

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

Exactly the point. We have a patch to distutils that lets you build an
installer with only cmopiled files (no source) to do this very thing.
See the following:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793069&group_id=5470

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

I think as long as you 1) release the source code to the LGPL'ed part
and 2) allow people to substitute in a different library (with Python
that's easy) you will be safe with no problems...
Whether the original library will work with your game is not an issue,
as long as people have the ability to substitute in a modified library

David

 

[Pete Shinners]

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 ?

Pygame is LGPL specifically so you can use it in close-sourced projects.
For an example of a shareware pygame project, see BaseGolf,
http://alitius.com .

In a nutshell, the LGPL allows you to use the library "as-is". If you do
make any changes to pygame itself, you must release those changes under
a compatible license (or maybe the exact same license, unsure).

Once you have made those changes available your obligation is finished.
If future generations want to take you changes and apply them to a
modern pygame, the burden is on them.

Of course, since Pygame itself is written on top of basic SDL, you could
actually add quite a bit of functionality that would still be considered
part of your game, and you need not release that. As long as you are not
recompiling pygame or modifying things inside .../site-packages/pygame
you don't need to release source.

Of course, if you do release the source for your game, it helps ensure
future generations could get your game running on modern computers. Or
just play it on other platforms than you originally intended (osx,
linux, bsd, etc)