Distributing closed source modules

[Dave Brueck]

Fuzzyman wrote:
> Dave Brueck wrote:
>> 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).
>>
>

> 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