Protecting Python source

[Craig Ringer]

On Mon, 2004-11-29 at 18:04, Peter Maas wrote:

> I can think of 3 reasons to prevent tampering:
> 
> - You need money and want to sell your software on a "per seat" basis.

If you mean that you therefore must add built-in copy-protection, then
sure. Users will always get around it if they really want to, so
tamper-resistance is probably closer to the truth, but it'll slow them
down.

On the other hand, one can license software per-seat quite effectively
without software enforcement, or with only informative software
enforcement ("By the way, you appear to be over your seat count."). In
many cases this is good enough - the user can always crack / steal your
software, tamper resistant or not (witness: the games industry), and
code without copy protection is a LOT friendly.

For example, my employer currently relies on software that has a dongle.
The software manufacturer has gone out of business, so if that dongle
dies we're in trouble, as development of a replacement is moving slowly.
In future, if we're given the choice between a product that's superior
in price or functionality but has opressive copy protection and one
that's more limited or more expensive, but has no software enforcement
of copy protection, we'll buy the inferior or overpriced one.

We're quite capable of monitoring our own license compliance. Those who
aren't are also generally quite capable of 'fixing' the software, tamper
resistant or not, so I really don't see the point.

> - You don't want customers to fiddle with your code and then innocently
>    call for support and demand "bug fixes" for free.

There, what you really want is tamper-evident code not tamper-proof
code. That's quite a bit more practical IMO, and may be a good place to
look at digital signing.

> - Your customer demands closed source because the code contains trade
>    secrets.

My understanding is that that's never guaranteed safe, no? Or are
restrictions against reverse engineering now commonly enforcable?

--
Craig Ringer