I think that if mod_perl programs could be very well encrypted, this
technology would be a little more used than it is now, but they
can't, and
if this is a disadvantage for some of us, we shouldn't say that the
programmers shouldn't need such a thing.
Teddy makes a good point. This discussion comes and goes on various
Perl lists once a year or so, and the general consensus tends to be
that Perl programs should not try to encrypt or obfuscate themselves.
I think this stems more from the ideals of Open Source, and less from
the practical issues involved with copyright protection and the
possibility of prosecuting infringers, even within the USA. Is anyone
aware of a successful lawsuit by an independent Perl programmer for
breaking copyright? I doubt most have the resources to pursue
lawsuits, much less monitor for infringements. It's surprising to me
that the same Perl programmers who have a traditionally libertarian
[?] bent would in the same breath argue that the court is the
solution to our desire to protect our code. Eesh!
It will always be true that a dedicated hacker will be able to
decompile, dump opcodes, or otherwise reverse engineer the work of
another, regardless of the language or file format. But the value of
compiling a program is not so much its security, but its illusion of
security, and discouragement of all but the most determined folks
from stealing the work of another. It's incorrect to claim that
compiling or encrypting code does not protect it to a large degree,
especially when the usual suspects are running CGI's hosted in a
shared environment on some big web server, with no real programming
know-how.
Anyway, I do regret that there isn't an elegant way to do this with
Perl. If you need this ability, Perl is not a good choice for your
project, unless you're wiling to compile a perl/mod_perl against some
C lib that will handle the job pre-interpreter. I know of places that
has been done before.
- Danny
