Distributing closed source modules

[Jiri Barton]

Hi,

I'd like to be able to distribute some python modules of my system (plugins)
without the source. So far, I have done this by including only the *.pyc
files. However, I have recently found they are platform dependent and
python version dependent.

This approach has been very convenient because I don't have to mess up with
__import__ and the like - which seem to be kind of a pain when inter-module
dependencies are introduced.

Can some one point me in another direction of protecting the code? I know
and this whole thing just does not sound right to me either but I am forced
to do so.

TIA, jbar

 

[Dave Brueck]

I'd like to be able to distribute some python modules of my system (plugins)
without the source. So far, I have done this by including only the *.pyc
files. However, I have recently found they are platform dependent and
python version dependent.

This approach has been very convenient because I don't have to mess up with
__import__ and the like - which seem to be kind of a pain when inter-module
dependencies are introduced.

Can some one point me in another direction of protecting the code? I know
and this whole thing just does not sound right to me either but I am forced
to do so.

Protecting code in any language is pretty tough and/or futile, but you can
Google the archives if you're interested in reading more on that.

Anyway, you can create a module on the fly like this (untested):

import new, sys
name = 'MyModule'
m = sys.modules[name] = new.module(name)
exec codeStr in m.__dict__

where codeStr is a string that contains the source code of your module (e.g.
from file('somemodule.py').read() ).

You can combine the above with whatever mechanism you come up with for
distributing the code itself. You could store it in an encrypted archive file,
you could download it on the fly from a remote server over a secure connection, etc.

-Dave

 

[Fuzzyman]

Jiri Barton wrote:

[snip..]

Hello Dave,

Protecting code in any language is pretty tough and/or futile, but you can
Google the archives if you're interested in reading more on that.

It's certainly something lot's of people are interested in. I guess it
depends who your audience is. If ytour code isn't for *mass*
distribution - the chances of people putting a lot of effort into
breaking it are greatly reduced. I don't htink it's necessarily futile.

Anyway, you can create a module on the fly like this (untested):

import new, sys
name = 'MyModule'
m = sys.modules[name] = new.module(name)
exec codeStr in m.__dict__

where codeStr is a string that contains the source code of your module (e.g.
from file('somemodule.py').read() ).

This is one of the better solutions I've seen. (Probably because it's
*not* very complex). The stored modules can be well encrypted.
Obviously the decryption code will be in the main code - but I guess it
can be obfuscated pretty well.

I like it.

Regards,

Fuzzy
http://www.voidspace.org.uk/python

 

[Dave Brueck]

Dave Brueck wrote:
It's certainly something lot's of people are interested in. I guess it
depends who your audience is. If ytour code isn't for *mass*
distribution - the chances of people putting a lot of effort into
breaking it are greatly reduced. I don't htink it's necessarily futile.

By "futile" I meant that, if the code ends up running on a user's machine, then
a sufficiently motivated person could crack it wide open, regardless of
implementation language - the only way to truly protect the code is to never let
it out of your hands (i.e. it's accessible just via a web service).

-Dave

 

[Fuzzyman]

futile.

By "futile" I meant that, if the code ends up running on a user's machine, then
a sufficiently motivated person could crack it wide open, regardless of
implementation language - the only way to truly protect the code is to never let
it out of your hands (i.e. it's accessible just via a web service).

Hello Dave,

I understand what you are saying - using hte word 'futilew' implies
that code is *likely* to be broken, not that it is *theoretically
possible* for it to be broken. If code has a small user base it is
probable that there is plenty that can be done to make breaking the
code a lot harder. There are also legitimate reasons why someone would
want to do this. 'Futile' is definitely a misleading response 3

It's a question that often comes up on comp.lang.python - and the reply
is often "don't bother, it's not possible - and why do you want to do
that anyway". This is a response that is likely to turn people towards
other languages....

Best Regards,

Fuzzy
http://www.voidspace.org.uk/python

 

[Dave Brueck]

I understand what you are saying - using hte word 'futilew' implies
that code is *likely* to be broken, not that it is *theoretically
possible* for it to be broken. If code has a small user base it is
probable that there is plenty that can be done to make breaking the
code a lot harder. There are also legitimate reasons why someone would
want to do this. 'Futile' is definitely a misleading response 3

Not really. For all practical purposes, shipping .pyc files is probably
sufficient for most of the software out there: (1) it's a high enough "fence"
for almost all users, (2) for most programs, getting the source code and being
able to do something with it are two very different things, and (3) for most
programs, there really is no proprietary magic worth protecting.

So, when somebody says it's not good enough, and they need something better, I
have to admit I'm initially skeptical of their perceived need for "better"
protection of the source code (there _are_ some cases where it should be
protected, but they are much less common than people seem to think). One of two
things is probably true in these cases:

1) The value of the source code is overestimated - yes, it's a nice program, but
there's not really anything in there to warrant the higher
development/deployment/debugging costs associated with more security. As such,
nobody is really going to care enough to crack the code. And if anybody does,
it's unlikely that they'll actually do anything with the code. Thus, the effort
to secure the code more is futile - it's ineffective because the effort will
never provide any benefit.

OR

2) The code really does have some innovative, proprietary algorithm, like a
video codec with wildly improved compression (that for some reason you've
implemented in pure Python ;-) ). If the value of the code is really high, then
no amount of security is going to prevent people from getting at it - trying to
protect your code is futile because no matter how high a wall you create,
sufficiently determined people will climb over it. Plus, protecting the source
code may be the least of your worries (if they're willing to steal your code,
they may just as well be willing to use your library illegally, etc.).

It's a question that often comes up on comp.lang.python - and the reply
is often "don't bother, it's not possible - and why do you want to do
that anyway". This is a response that is likely to turn people towards
other languages....

Perhaps the response could be framed better, but at the same time it _is_ a
pretty honest response, and maybe Python really _isn't_ the language for such
people. It's just like people who ask for curly braces - Python is not the
language for them. So if I asked for braces, a lot of the c.l.py responses would
be geared towards helping me understand that they aren't really needed, but if I
insist that I have to have them, then maybe Python isn't for me.

So, when the question comes up, I don't mind offering some suggestions, but the
suggestions will always include the disclaimer that it's probably a waste of
time & effort - IMO leaving that part out would be misleading.

-Dave