Python executables?

[Geoff Howland]

On 27 Jun 2003 09:24:22 +0950, Ben Finney
<bignose-hates-spam at and-zip-does-too.com.au> wrote:

>> This solves the problem of giving python programs to users who don't 
>> have python but doesn't solve the problem of the source "secrecy" 
>> (copyright).
>
>Wrong problem.  If you want to hide your source code from your users,
>don't expect help from free software programmers.

I thought about this for a few days before responding (and Im sure I
did a few other things too  ;) ), but I wanted to comment on this.

I think everyone that uses Python wants it to gain acceptance for the
great language that it is.  I believe that stating an attitude in this
way is pretty counter productive in gaining any kind of wide-spread
acceptance.

Most of the replies to this request didn't mention the concept of NOT
protecting the software, but 2 did to different degrees.  As someone
who uses and like open source software, and is slowly starting to
release some things as open source, and ALSO someone who sells
software and will continue in the future to sell software, I can say
that nothing turns me off more to a community than being told what my
goals should be.

I can understand wanting everything to be open, but thats not reality
and it never will be.  Some people will always want things
proprietary, and they will only work within systems that allow that.
I think to be truly successful, systems will have to allow for this
and make it easy to do.

Currently Python does not make this REALLY easy to do, and in the
privacy portion, I believe its not even possible.  This was a big
concern for me when I released my last for-sale software, but I just
decided I didn't care that much, and I love working in Python.

Some people will care enough, and will avoid Python because the
ability to protect their end results aren't there.

So far, the only semi-workable way to do this would be something like:

- Build a C program that embeds Python.
- Encrypt all the Python script/bytecode files.
- On runtime, decrypt the files and then execute.

Optional:

- Change the bytecode values in the Python source, and include your
new Python with different bytecode values.

I tried this last thing just to see if it would work, and I got some
problems compiling initially, so just gave up, but I think in theory
it should work.

Ignoring the Optional portion, this semi-solution is not actually very
secure.  It does however move the problem into having to decompile a C
program, and then get it to decrypt the Python files.  Then the normal
Python bytecode -> source.  It means any cracker will have to know
something about both C and Python to do it, so a bit more barrier to
entry.  It also means that in the US, the (vile and despicable, but
present) DMCA laws will make it a much more severe crime because
"cryptography reverse engineering" needed to be applied, and may at
least reduce corporations from doing this for fear of
lawsuits/criminal charges if they are exposed.

Anyway, this is a good bit of work and not a great solution, but is
there anything else?  If Python is to have avenues of support in all
walks of the software industry, will something like this be required?

>From what I understand, there are also very good Java decompilers, but
no one seems to complain about Java's lack of security.  Perhaps it is
because it is seen as something that is really "compiled" while
Python's loose compilation seems more whimsicle.

I think Python faces a lot of different public relations problems, and
just thought I'd pipe up about one that I have looked at myself, and
that I think most people coming into the Python world are faced with
and have to decide whether to ignore or not.


-Geoff Howland
http://ludumdare.com/