RE: [PHP] Re: "Self Destruct Code" & "Copy Protection"
doing anything to the code is futile at the end of the day no matter how
smart it is, if it's coded, and runs on their server, they could easily
change themselves via an in-house/external resource who know how to
'fix' code.
-Original Message-
From: [-^-!-%- [mailto:[EMAIL PROTECTED]]
Sent: 10 May 2002 22:46
To: Jay Blanchard
Cc: [EMAIL PROTECTED]
Subject: [PHP] Re: "Self Destruct Code" & "Copy Protection"
I agree. We have many out of states clients, and all were required to
(and have) sign a contract. There are many ways to deliver contracts,
you
should not have to risk not getting paid because of delivery logistics.
You can use:
e-mail
fax
fedEx, Ups, or any other delivery systems.
-use Adobe's PDF Writer to convert to contracts to PDF, so clients
cannot
change the content.
We've successfully used the following processes:
1) E-mail original contract--> client sign and mail
it back.
2) E-mail original contract--> Client signed and fax it
back to us.
3) E-mail original contract --> Client signed it, scanned the
pages, and e-mail us the scanned pages (in this case, the scanned
images).
We then print the scanner pages, eh voila! A signed contract.
3) For rushed jobs, we've even had clients submit an electronic
agreement/permission, in conjunction with a hard copy. The
electronic
letter would state (a) that they've agreed to our terms (b) that the
hard copy is in the mail, and should arrive by a certain date (c) we
have permission to begin development with the prices listed in the
contract
(d) If the hard copy is not received within the listed timeline,
then
the electronic copy will take precedence over all documents, and
they
automatically agree to ALL of our terms. Those that were, and that
were not listed, on the original contact.
{small encouragement to get the original docs in}
Overall, we pretty much have zero tolerance when it comes to contracts.
No
contract, no work. Clients have the tendency to want a lot more than
their budgets can support, and they will try to get over the 'little
people'. They also tend to want to change things, late in the
development
process. This can give a new definition to the word 'HELL'.
The best way to prevent being cheated, is to have a WRITTEN agreement.
Once that agreement has been signed, stick to it. Do not change any
portion of it, because it will comeback to haunt you.
On the technology front===
How about this idea?
PHP's FOPEN() function makes it really easy to access remote
information.
Suppose, for example, that you leave the application's configuration
file
on your server, and have the program access it via FOPEN().
Whenever the program runs, it will need to access the configuration file
on your server, to initial the application's parameters.
if the client doesn't pay, then you simple disable the
configuration file on your server. Since they will not have access to
the
configuration file, then they will not be able to change anything.
Plus, changes they make to their own servers (like changing login info)
will not prevent you from controlling the unpaid program.
Once all payments are in, you can transfer the configuration file to
their
server.
I haven't tried this, but I've been thinking about it. Just thought I'll
put it out there. The only limitation, AFAIK, is that of FOPEN(). If I
remember correctly, fopen() will not process any codes in the file that
it is opening.
You'll have to work around that.
Just add that to the Idea Bin, it may lead to a better solution.
-john
_+---+_
P E P I E D E S I G N S
www.pepiedesigns.com
"Providing Solutions That Increase Productivity"
-+___+-
On Wed, 8 May 2002, Jay Blanchard wrote:
> [snip]
> As any good developer out there knows, first you call them "new
friends"
> then "clients" and sometimes it goes to "S.O.Bs" and "bast**ds" and
the
> worst part for me is I am not in the states but offer services to a
lot of
> U.S clients so a actual contract is pretty much out of the question.
> [/snip]
>
> Why is an actual contract out of the question? With FedEx, UPS, Fax
> Machines, postal services of all types, and electronic contracts with
> electronic signatures it shouldn't matter where the programmer is,
even if
> it is not the same locale as the client.
>
> Jay
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: "Self Destruct Code" & "Copy Protection"
I agree. We have many out of states clients, and all were required to
(and have) sign a contract. There are many ways to deliver contracts, you
should not have to risk not getting paid because of delivery logistics.
You can use:
e-mail
fax
fedEx, Ups, or any other delivery systems.
-use Adobe's PDF Writer to convert to contracts to PDF, so clients cannot
change the content.
We've successfully used the following processes:
1) E-mail original contract--> client sign and mail
it back.
2) E-mail original contract--> Client signed and fax it
back to us.
3) E-mail original contract --> Client signed it, scanned the
pages, and e-mail us the scanned pages (in this case, the scanned
images).
We then print the scanner pages, eh voila! A signed contract.
3) For rushed jobs, we've even had clients submit an electronic
agreement/permission, in conjunction with a hard copy. The electronic
letter would state (a) that they've agreed to our terms (b) that the
hard copy is in the mail, and should arrive by a certain date (c) we
have permission to begin development with the prices listed in the contract
(d) If the hard copy is not received within the listed timeline, then
the electronic copy will take precedence over all documents, and they
automatically agree to ALL of our terms. Those that were, and that
were not listed, on the original contact.
{small encouragement to get the original docs in}
Overall, we pretty much have zero tolerance when it comes to contracts. No
contract, no work. Clients have the tendency to want a lot more than
their budgets can support, and they will try to get over the 'little
people'. They also tend to want to change things, late in the development
process. This can give a new definition to the word 'HELL'.
The best way to prevent being cheated, is to have a WRITTEN agreement.
Once that agreement has been signed, stick to it. Do not change any
portion of it, because it will comeback to haunt you.
On the technology front===
How about this idea?
PHP's FOPEN() function makes it really easy to access remote information.
Suppose, for example, that you leave the application's configuration file
on your server, and have the program access it via FOPEN().
Whenever the program runs, it will need to access the configuration file
on your server, to initial the application's parameters.
if the client doesn't pay, then you simple disable the
configuration file on your server. Since they will not have access to the
configuration file, then they will not be able to change anything.
Plus, changes they make to their own servers (like changing login info)
will not prevent you from controlling the unpaid program.
Once all payments are in, you can transfer the configuration file to their
server.
I haven't tried this, but I've been thinking about it. Just thought I'll
put it out there. The only limitation, AFAIK, is that of FOPEN(). If I
remember correctly, fopen() will not process any codes in the file that
it is opening.
You'll have to work around that.
Just add that to the Idea Bin, it may lead to a better solution.
-john
_+---+_
P E P I E D E S I G N S
www.pepiedesigns.com
"Providing Solutions That Increase Productivity"
-+___+-
On Wed, 8 May 2002, Jay Blanchard wrote:
> [snip]
> As any good developer out there knows, first you call them "new friends"
> then "clients" and sometimes it goes to "S.O.Bs" and "bast**ds" and the
> worst part for me is I am not in the states but offer services to a lot of
> U.S clients so a actual contract is pretty much out of the question.
> [/snip]
>
> Why is an actual contract out of the question? With FedEx, UPS, Fax
> Machines, postal services of all types, and electronic contracts with
> electronic signatures it shouldn't matter where the programmer is, even if
> it is not the same locale as the client.
>
> Jay
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Self Destruct code
Keep some vital part of the code separate, ie on your own host... such as the ability to add new users, or the calendar-file for next month, or whatever. Their system works fine, and as soon as they pay they get the last module and are on their own, but if they fail to pay you can pull the plug. And because it's something *missing* rather than an additional test in the code they have, it's much harder to work around. "Phpcoder" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi > I have a funny request; I wrote a system for a client and am rather > concerned that I am not going to receive payment for the work done. They > want me to hand over the code before they are willing to pay, so > basically I will be left at their mercy; if they don't pay, they will > still have a working version of the system... > So, is there any way I can inconspicuously code in some boo-boo's that > are time related etc. Something that will bomb the mysql tables or break > some code if it is not "unlocked" within a month etc. > I'm not sure if people out tjere might have existing safeguard tools > etc, so I'm open for suggestions. > PS, I know about Zend's encrypter, but since it will live on their > server, I don't think it will help much since they will need the > decrypter on there anyway right? > > Thanks > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
