anyone knows how to resolve this problem?
amyng...@yahoo.com
out. They don't want to pay for it yet. So I'm willing to let them
use it for a month. If they like it, they can negotitate on the
pricing, and if they don't want to use it, then, after 30 days, this
program will stop working.
Here's the question:
How can I make it work for a month only?
1) If I write the code to see if the date is later than May 15, 2009,
then, the C program stops. But the problem is that they can change
the current date of their Linux or Solaris computer, say, back to
January 1, 2009, and this program will run again. So I don't think
this method will solve the problem.
2) Or if I put a counter into a file somewhere on the computer. Say
the counter will stop after this C program runs for the 100th time.
The problem with this is that if they backed up the whole hard drive,
they will likely back up that counter file. If they restore that file
back, the counter might be only at 1, 2, etc. So, the software will
run again. I don't think this method will solve the probem either.
Any suggestions to solve this problem? Thanks.
Thad Floryan
> I have a compiled C program that this small business would like to try
> out. They don't want to pay for it yet. So I'm willing to let them
> How can I make it work for a month only?
>
> 1) If I write the code to see if the date is later than May 15, 2009,
> then, the C program stops. But the problem is that they can change
>
> 2) Or if I put a counter into a file somewhere on the computer. Say
One solution is to query a "outside" system's date/time over the net.
If you write some networking code, this would be fast in operation.
Assuming wget exists on the system in /usr/sfw/bin/wget (or
whereever),
note the output of this command (using Yahoo):
$ wget -S http://yahoo.com
If you place the following example line in your C program:
system("/usr/sfw/bin/wget -S http://yahoo.com &> /tmp/datexyz");
your program could then read the /tmp/datexyz file, parse the items
on the "Date:" line, delete the created /tmp/datexyz file, then do
whatever you want as a result of the date&time info parsed.
It's a qwik'n'dirty solution but may be all you need. :-)
ThanksButNo
> would like to try out. They don't want to pay for it yet.
> So I'm willing to let them use it for a month. If they
> like it, they can negotitate on the pricing, and if they
> don't want to use it, then, after 30 days, this program
> will stop working.
>
> Here's the question:
>
> How can I make it work for a month only?
>
> 1) If I write the code to see if the date is later
> than May 15, 2009, then, the C program stops. But the
> problem is that they can change the current date of their
> Linux or Solaris computer, say, back to January 1, 2009,
> and this program will run again. So I don't think
> this method will solve the problem.
>
Don't be paranoid. No reasonable business is going
to run their computers back-dated just so they they
can steal software from one independent contractor.
It's not worth it to break everything else.
"Hey Charlie, how's come these quarterly P&L reports
all say 2008? They've been like this for 6 months now,
the tax accountant is starting to get worried!"
Tell them they have a 30 day trial, tell them it will
stop working after 30 days, and trust them to either
pay up or stop using it.
You can even actually put in that time-bomb if it makes
you feel safer. Set it up to check the date first thing,
and if it's past the deadline, exit gracefully with a
polite error message.
"PAY UP, SUCKA!!" no, no, no, not like that!
The real solution is to build a working relationship of
mutual trust. Earn their trust, and give them the
respect and trust they earn and deserve. That way,
they'll not only pay you for the work you do now (be
prepared for LATE payments), but they'll likely contract
you for more work later.
If you can't trust them, well, I don't know what to
tell you. I'd like to say, don't do business with
people you can't trust, but I understand how tough
the market is these days.
/:-/
Casper H.S. Dik
>This sort of thing is why companies do remote licensing. A friend did
>the licensing for his company's internet-based product. On initial
>startup, the product checks the company license server. If it can't
>reach it, it won't run. If it does reach it, a crypto handshake
>verifies the time-stamp and validity of a license (they expire yearly
>with the support contract). If there's no contract, the IP and ethernet
>address are added to the database and a 30-day trial license is granted.
>If they don't get a valid license in 30 days, the product stops working.
>The time is gotten from the license server over the net, which precludes
>the customer from resetting the clock.
>Electronic Arts does this all the time with their games.
Perhaps nice for games, not such a good idea for business applications.
I think you should trust customers more; often it might be sufficient
to print a "nastygram" whenever people use the unlicensed copy.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Andrew Gabriel
Also, you need to be very careful what you do when the license
expires. In some cases, in some countries, just refusing to do
anything may land you with a whopping great bill for damages,
as ICL discovered in the UK.
IANAL, but from what I've seen of this and similar cases, make
sure your software, even when unlicenced, does not prevent the
user from accessing any data they previously stored in the
application.
Never allow a license which is the subject of a legal dispute to
expire (that decision becomes the court or the judge's choice,
and not your unilateral decision).
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
ThanksButNo
> out. They don't want to pay for it yet. So I'm willing to let them
> use it for a month. If they like it, they can negotitate on the
> pricing, and if they don't want to use it, then, after 30 days, this
> program will stop working.
A tad more I happened to think of --
No matter how hard you try, there's going to be something
about the product they don't like, want changed, want
improved, or -- and let's be honest, folks -- fails to
work *correctly*.
You know -- BUGS. All software has at least one.
While you have your customer on the 30 day lease, have
you given any thought to how to handle requested time
extensions when (not IF) they find something they want
differently and you have to go in and fix?
Be prepared to negotiate which improvements are outside
of the original scope, and thus warrant extra payment,
vs. which are actual bug-fixes. Be prepared to give up
a little more than you'd like to give up, especially if
you want to keep them as future customers.
That's all part of setting up that working relationship
of mutual trust. They need to know you're ready to go
that extra mile to make sure your product meets their
needs.
And be prepared to live off your credit cards for a while.
If they decide they like it, and they decide to pay, no
matter what kind of company they are, they WILL pay you
LATE. Unfortunately, a working relationship of mutual
trust rarely translates into getting paid on time!
\:-\
Richard B. Gilbert
A contract can make provision for late payment and/or non-payment.
You can deliver your product with, say, a thirty day trial license.
If they don't pay you it stops working and won't work again until they
do pay you!
Get a good lawyer who is knowledgeable about these issues.