Python obfuscation

[Ben Sizer]

Mike Meyer wrote:
> > I have considered distributing my program as open source but with
> > encrypted data. Unfortunately anyone can just read the source to
> > determine the decryption method and password. Maybe I could put that
> > into an extension module, but that just moves the weak link along the
> > chain.
>
> This isn't a Python problem, it's a problem with what you're doing. Try
> Alex's solution, and put the data on a network server that goes
> through whatever authentication you want it to.

To be fair, I don't think I have accused Python of having a problem,
just mentioned that this is an area where Python is less appropriate
than other languages which have a significant degree of obfuscation as
a side-effect of their use.

I already explained elsewhere that putting the data on the network is
not always appropriate. I know people love web services and the like
these days, but they are not the answer to everything. Even in
situations where it is practical to keep all the data server-side, it
still just moves the problem rather than solving it, in that instead of
people copying the data they now copy the authentication for the data.
Anecdotal evidence from experiences with online registration for
Half-Life 2 and Windows XP would suggest that this method ends up
annoying more legitimate customers than the usual copy-protection does.

> It is? Is the Python disassembler so much advanced over the state of
> the art of binary disassemblers, then? Or maybe it's the Python
> decompilers that are so advanced?

Decompyle (http://www.crazy-compilers.com/decompyle/ ) claims to be
pretty advanced. I don't know if you can download it any more to test
this claim though.

> As far as I can tell, the only real
> difference between Python bytecodes and x86 (for instance) binaries is
> that Python bytecodes keep the variable names around so it can do
> run-timme lookups. That's not that big a difference.

It makes a lot of difference when you're hunting around for something
or trying to understand a bit of code. Python bytecode (or at least,
the output from dis) is also a lot more straightforward than x86 or 68K
assembly to decipher.

> > No, certainly not. But if you can mitigate your losses easily enough -
> > without infringing upon anyone else's rights, I must add - then why not
> > do so.
>
> Elsewhere in the thread, you said:
>
> > I'd just like to make it non-trivial to make or use additional copies.
>
> How do you do that without infringing my fair use rights?

Yes, I suppose my terminology there was wrong. The term I should
probably have used was 'distribute usable additional copies'. Generally
speaking I believe in the "like a book" interpretation of rights... you
should have the right to give it away, sell it to someone, lend it,
excerpt parts for review or criticism, but not to distribute additional
copies that essentially duplicate the original.

On the other hand though, what you term a 'fair use right' is not
necessarily viewed that way under law. The relevant part of the law (at
least in the US) says "it is not an infringement for the owner of a
copy of a computer program to make or authorize the making of another
copy or adaptation of that computer program provided [...] that such
new copy or adaptation is for archival purposes only", which is quite
distinct, legally speaking, from saying "you have the right to make a
copy or adaptation for archival purposes".

However, this is drifting more into the legal area which I am less
interested in. Really I'd just like to be able to use Python for my
work and am interested in finding the best way of doing so.

-- 
Ben Sizer.