On Feb 7, 2008 6:20 PM, Greg Donald <[EMAIL PROTECTED]> wrote:
> On 2/7/08, Daniel Brown <[EMAIL PROTECTED]> wrote:
> > Actually, Greg, I respectfully disagree. First, just because
> > there may be ways to reverse-engineer things doesn't mean it's a bad
> > idea to attempt to protect your code against such.
>
> Why would you encode to start with? The only reason I can think of is
> because you don't trust your client. So why are you doing business
> with people you don't trust?
Because who's to say you're selling to one client? If it's your
Intellectual Property, wouldn't you want to protect it, at least as
much as possible?
> > I know that people
> > can smash in the windows of my Durango and steal my equipment, but I
> > still lock it when I park it and go into the store. Why? Because I
> > don't want to make things easy enough for someone to be tempted to
> > take something. I know that if they want something badly enough,
> > they'll take it.... but I'm just not going to make it that easy.
>
> That's my whole point. Honest people aren't gonna steal your code
> anyway. Trying to prevent them from making a simple change when
> you're not around is pointless.
No, but it does allow for a better contract stating something
along the lines of, "in order to maintain a valid warranty, all
updates must be done by Company XYZ, at a fee of $n." However, I'll
agree to the point that, if you're selling something once-off to a
client, then it's ludicrous to encode the software. However, it still
doesn't make the practice of encoding "pointless."
> Would you have bought that Durango if the hood had been welded shut?
> I'm guessing you're not a mechanic, so you'll _never_ need to raise
> the hood, right? What about when you come out of the grocery store
> and there's a hot blonde who needs a jump because she forgot and left
> her lights on before she went in?
That's like comparing apples to vaginas. There's no similarity
between the two unless you *really* look for it and make a lot of
concessions. I may never need to look under the hood, but a qualified
mechanic - as so designated in the vehicle owner's manual, contract,
and warranty specifications (relate this to my first paragraph) - will
need access to the engine compartment. In my case, it would be the
dealer --- who is employed by the manufacturer of the code --- err,
car. ;-P
And if that hot blonde is there, I'll ask first if she likes apples.
> > And if Zend considered it "pointless", they probably would no
> > longer attempt to further develop - nor put their name on the line to
>
> Oh please, Zend isn't the first company to ever create useless
> software. Creation, in no way, proves usefulness.
Exactly. Humankind is a perfect example. Nonetheless, now you're
going on a separate tangent.
> > sell - the product line. By definition, pointless means
>
> I know where dictionary.com is, thanks :)
Cool. I wasn't sure, because I thought you'd have used it prior
to using the term "pointless" incorrectly. ;-P (Note: my smartass
remarks are only joking around, I'm not attacking you in any way. I
just really enjoy a debate.)
> > It also keeps script kiddies from typing "decode php" into Google
> > and being able to pull one over.
>
> I fail to see how Zend adding "decode" into their list of Google
> Adwords keeps script kiddies from doing anything. I used the Google
> Adwords example as confirmation Zend is well aware of existing
> decoders.
Yes, and I used the same phrase for searching as an example of for
what even a low-level "cracker" would first search. It doesn't mean
that Zend is or isn't aware of the existence. So this part, to me,
seems baseless and unrelated to the overall discussion, but feel free
to re-explain if my brain isn't grabbing hold properly.
> > While industry standards may not be
> > the lock that cannot be picked, proprietary obfuscation will keep
> > people who don't know what they're doing out of your code --- and if
>
> If you're paid to write code then write code, and then when you're
> done give them the code and collect your money. They paid for the
> code so why do you think you still own rights to it?
Again, I agree wholeheartedly, save for two situations:
1.) Multiple customers, such as an off-the-shelf script being sold.
2.) Contract retention. While the document should legally
protect your interests, your adding *A BENEFIT* to your product for
the client: deniability. If a huge bug is discovered in your scripts
that costs the client $10,000, they can turn around and say, "well, we
didn't touch the code because we couldn't, so the bug was already
there." However, with that risk comes the benefit of being granted
exclusive contracts for continued support on the scripts.
> > they possess the acumen and free time to be able to reverse-engineer
> > the code themselves, I honestly don't know why they'd pay someone to
> > develop the application in PHP for them in the first place.
>
> I honestly don't know where you find clients so dumb that they who
> would put up with not getting full source code for a paid project.
Hopefully by now I've illustrated enough points. For now, I'm
heading out of the office for the evening.
Well, at least that's the plan at this moment....
--
</Dan>
Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
