Front page | perl.bootstrap |
Postings from July 2000
Re: Obscuring code?
From:
Russ Allbery
Date:
July 25, 2000 15:20
Subject:
Re: Obscuring code?
Message ID:
yl8zupx374.fsf@windlord.stanford.edu
phil <phil@Stimpy.netroedge.com> writes:
> However, I must say that when I come to work to do a project for a
> client (for $$$), they will want to have an assurance that the code is
> safe. The developer will want the code protected from theft, from being
> looked at for possible exploits, and (let's face it) for job security.
Eep.
The standard answer at this point that one gets in comp.lang.perl.misc is
"I'd never hire anyone with that attitude to work on anything for me,"
particularly about the "not looked at for possible expoits" part. I'm
just saying this to clear the air up front; I'm not implying that you're a
bad programmer. But not wanting the code inspected for exploits *does*
give a bit of that impression.
The standard answer to "but I make money off of this and I don't want
people stealing it" is "that's what licenses are for" (and I think there's
some merit to that position). As for job security... well, again, this is
a frequently discussed topic. The general response is that if you can
show you write good code, that will get you more future contracts than
writing things and not really giving them to the people you wrote them for
and making them hire you to make any modifications.
There are a non-trivial number of people who write Perl specfically
*because* it can't be hidden easily in this fashion; you don't have to
worry about losing the source code, if you have the program you can tweak
the program for unexpected problems, everyone can learn from each other,
and so on. This is true in the proprietary world as well as the free
software world. If the application is non-trivial enough to charge for,
it's also going to be non-trivial for someone else to maintain and there's
going to be far more to it than someone could pick up by just reading the
code and using similar techniques.
> That said, Perl seems to lack a slick integrated function for this. Or,
> perhaps it could be done as an external module?
I'm guessing you'd encounter less resistance going that direction.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>