Presumably, your customer has paid you for the effort you devoted to software development, implementation and installation for this project. (If not, that's a separate issue for you to resolve.) That transaction having been completed, I think the more common practice in such projects is that the customer is able to alter the software as needed, in the all-too-likely event that the original installation must be adjusted to adapt to changes the overall web server environment, or to keep up with inevitable changes in the customer's desired artwork, etc.
If the intent of your contract was to ensure that the customer would be dependent on you to make all such adjustments in the foreseeable future, then my first reaction would be "Why agree to such a contract in the first place?"
In any case, enforcing such a condition in a Perl application not only runs counter to much of what is good about Perl as an application development tool, but also turns out to be virtually impossible to do in any rock-solid reliable way. For example, you could have delivered the source code for your app in "encrypted" form -- there are CPAN modules that support this -- but it is widely recognized that this form of hiding the source code is only a hurdle, not an absolute barrier.
I've seen a web app distributed by a vendor of NAS systems that used encrypted perl code, and I'll admit that it stopped me from trying to make some simple changes (which would have kept some lame-brained warning messages from clogging the root account's mbox at five-minute intervals...) We did have a support contract that should have led them to solve the problem once I reported it, but before they got around to that, we just ended up ditching that vendor and moving to another NAS solution -- there were other problems as well, and the closed nature of the system just made it all too cumbersome to deal with. Anyway, while I haven't done it myself, I gather that it's entirely possible for any encrypted script to be loaded for execution and then dumped to a file by the perl interpreter in such a way that the source code is in fact quite legible.
So you could try something like that next time (actually, the Acme::Bleach module might be as good a form of "encryption" as any). Or you might follow l3nz's suggestion, and include some obscure feature in your code that will do something unambiguous (but not unsafe) in terms of identifying the source code -- e.g. have it produce a hidden tag in the HTML output that reports the MD5 checksum of the script file being run, or something of that sort.
But when your customer cuts you off from direct access to their copy of your source code, there's no way to guarantee that this particular contract clause can be enforced, in the sense of using legally available evidence to prove non-compliance. And of course, they could decide to implement an equivalent solution some other way -- this is a common possibility with any perl application, and it certainly blurs the situation for your sort of contract.
In reply to Re: OT: Getting at source code of CGI scripts
by graff
in thread OT: Getting at source code of CGI scripts
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |