develooper Front page | perl.bootstrap | Postings from July 2000

Re: Obscuring code?

Thread Previous | Thread Next
July 25, 2000 15:49
Re: Obscuring code?
Message ID:
On Tue, Jul 25, 2000 at 03:19:59PM -0700, Russ Allbery wrote:
> phil <> 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.

	Actually, this was suggested and discussed with management. 
The response you suggest is definitely not the take I've received from
the environments I've been in as a professional web developer over the
last several years.  Protecting the company and the client will (or at
least should never) be viewed unfavorably by management. 

>  But not wanting the code inspected for exploits *does*
> give a bit of that impression.

	Keep in mind, I mean hiding it from poeple outside of the
company (not including the client).  Of course you want others (you
trust) to examine the code.
> 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).

	Hummm... I think there needs to be a mechanism to keep honest
people honest.  Is there harm in this?  Breaking of license agreements
(sorry to burst any bubbles) is a very common occurance.  To make
things more distresssing, it is expensive and hard to police license

>  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.

	I don't like the job security aspect of it.  It gives me a bad
taste in my mouth.  I like the philosophy of 'designing myself out of
the project'.  Otherwise you end up with lots and lots of old stuff
which you have to maintain. ;'p
	But, this is a very honest 'need' that companies/developers
have.  Code is generally created under one of two conditions: 1)
client pays for the time to implement an idea (they own the result),
or 2) client buys the service to use the code (we own the code). 

> 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.

	(Shrug) OK.

>  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.

	Keep in mind that I'd prefer a two-way obscuring so the code
is easily maintained and shared w/i a select group (the company
and/or client).

> > 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.

	OK.  I'd like to offer an additional comment:  I'm sure Perl
is being used for very evil purposes right now (processing kiddie
porn, who knows?).  Obscuring seems less dangerious to abuse to me.

	In the end, it's up to the end user on how they use the tools.
Taking the tools away in fear that they might be misused is a bit
big-brother-ish, which seems more against the nature and philosophy of
Perl than some of the smaller examples I've read in this thread so

	But, I am impressed by the passion and intelligence in the
replies.  And, the resistence to flame. :')


Philip Edelbrock -- IS Manager -- Edge Design, Corvallis, OR --
 PGP F16: 01 D2 FD 01 B5 46 F4 F0  3A 8B 9D 7E 14 7F FB 7A

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About