How protect proprietary Python code? (bytecode obfuscation?, what better?)

[Ben Sizer]

Alex Martelli wrote:
> Ben Sizer <kylotan at gmail.com> wrote:
>
> > I don't know. In terms of copy protection, popular off-the-shelf
> > software is going to get cracked whether it's written in Python or x86
> > ASM, that much is true. But in terms of perhaps protecting innovative
> > algorithms from competitors, or something similar, compilation into
> > native code does a great job of hiding your work. Not a perfect job,
> > but a good enough job.
>
> If they're truly worth protecting, they're worth reverse engineering.

It's a sliding scale though. You don't need to be able to stop
everybody to make it worthwhile.

> Remember, the competition includes excellent programmers working in
> countries where $10 an hour's salary is luxury and IP law enforcements
> non-existent, so the cost to reveng is not as high as you might think.

Whether $10 is a lot or a little is not as important as whether that
$10 could be better spent. It's easy to drill down far enough to break
copy protection but nowhere near as easy to derive a high level
algorithm from the assembly language. So in the latter case, a little
protection goes a long way.

> > I know some people talk a lot about using web services to keep the
> > proprietary data behind a secure server, but there is a large number of
>
> Ah yes, that would be me;-).  Except that I don't limit my advice to
> proprietary DATA -- it also applies to CODE worth keeping secret.

Code is data, data is code. :)  I meant it to refer to all information
stored that way.

> > applications where this is not practical - eg. image/audio processing,
> > computer games, artificial intelligence, or several other applications
> > with heavy real-time or cpu-intensive requirements, or embedded systems
> > that don't have web access.
>
> Fewer and fewer systems "intrinsically lack" net access.  For example,
> good (costly) computer games more and more need net access to be played
> in the best way (multiplayer etc).

Sure, but there's still many, many programs that don't fit that
criteria. Nor are people generally happy about being compelled to use
online services to 'activate' their games.

> "CPU intensive" is a weird reason to want to avoid keeping in a well
> protected environment any code that's really worth money -- if it IS
> worth that much you're no doubt charging enough for it to afford
> supplying the CPU power to your customers (whatever your business model,
> say pay-per-use or subscription levels with different maxima, etc etc).

Maybe I wasn't making myself clear - I just meant that you can't be
doing round-trips to a web server for per-pixel calculations.

-- 
Ben Sizer