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 -- http://mail.python.org/mailman/listinfo/python-list
