> -----Original Message----- > From: Daniel Brown [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 07, 2008 7:10 PM > To: Greg Donald > Cc: php-general@lists.php.net > Subject: Re: [PHP] PHP Source code protection > > 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); } ?>
Has anybody mentioned ionCube? http://www.ioncube.com/ It's always the choice for encoding DirectAdmin commercial templates and plugins (not saying it is the best, just the common practice in DA's commercial world). Also: 1 - I believe the fact that we don't "encode" (read "compile") our scripts is tightly related to the fact that we don't have a bytecode interpreter (say JIT compiler or something?) bundled into PHP. If we had, we'd all release the compiled scripts for "performance" reasons and "forget" about distributing the source code (clients don't usually ask for source code, they usually don't even know what source code is). So, we don't encode them, compile them, "binarize" them because we can't rely on anything installed in hosting XYZ. Existing "pure PHP" obfuscating solutions are not worth the try (my opinion) and only compromise performance or break working code (my opinion again). 2 - Decoding an encoded script will not (usually?) restore the "original source code", but rather a "reverse engineered binary code" that would become the encoded script if it was again processed by the encoding software. So, if source code alone is hard to read sometimes, just imagine "reverse engineered binary code". So, I think that encoding PHP scripts for copyright, security, or whatever reason, is as valid as using serial numbers and activation codes for desktop software, despite we all know that we can get key generators and cracks in the p2p networks, such as ed2k and bittorrent. 3 - If the PHP license allows for commercial use of PHP scripts and allows for encoding the sources, I don't see any compelling reason or commandment to not do so. If you give away something, nobody has the obligation of doing the same. It is the client who has to make the choice; and other than that, it is you who have to either start encoding your files or placing huge banners in your site with the phrase "WE DON'T ENCODE OUR WORK", or just do nothing. Just to make it clear, we don't encode our work :), but only because: 1 - We trust ourselves, that nobody can get a better deal for our clients. 2 - If we offered source release as an extra, no client would want it and it would still be a management pain for us to debug->encode->upload. The only concern for a client is that "the damn thing works". If "the damn thing doesn't work" they would just contract someone else, source code or not. It doesn't make any difference. 3 - Either you have to buy encoding software and beg all your clients have the "decoding" counterpart installed in their servers, or force all your development clients to host with you, or you have to use pure PHP solutions, which all have some performance hit. But even trusting ourselves, we don't release the source code until the last cent of a project is paid. In the meantime, we host the project. We don't have to trust the client 100%, and that's why we all sign contracts and lawyers exist. In business you can be very friendly and complaisant with your clients; but the only thing you can (barely) trust is a signed piece of paper reviewed by a lawyer. Don't misunderstand me, some clients are great to work with, even those who come to you with "cutting-edge" ideas for which you spend a weekend without seeing sunshine. But there are some who just "change their minds" about a critical point in the middle of a project and will want you to rewrite the whole thing from scratch threatening you that they will go somewhere else without paying you a cent (there are people like this). All in all, encoding is either a critical thing, or just another link in the chain, but it is as valid as compiling a C# application and some people may have very specific needs to do so. Regards, Rob Andrés Robinet | Lead Developer | BESTPLACE CORPORATION 5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308 | TEL 954-607-4207 | FAX 954-337-2695 | Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE: bestplace | Web: bestplace.biz | Web: seo-diy.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
