Method for providing a trail period on a program

[Larry Bates]

I'm searching for a good way to provide a "trail
period" (something like 90 days) for a commercial
application that I'm writing. I'd like something
that can easily stop working 90 days after
installation. Can anyone point me to something
that exists already?

Thanks in advance,
Larry Bates
Syscon, Inc.

 

[Ben Finney]

I'm searching for a good way to provide a "trail period" (something
like 90 days) for a commercial application that I'm writing. I'd like
something that can easily stop working 90 days after installation.

Why do you want to break your user's programs to gain money? Will they
not pay for your work without their programs breaking? What does that
say about the value of your work?

 

[Josiah Carlson]

I'm searching for a good way to provide a "trail

period" (something like 90 days) for a commercial
application that I'm writing. I'd like something
that can easily stop working 90 days after
installation. Can anyone point me to something
that exists already?

Using windows registry pseudo-code

if stoptime_not_in_registry:
stoptime = time.time() + 90*24*3600
store_stoptime_in_registry(stoptime)
if time.time() < stoptime:
continue working
else:
give registration warning and quit


FYI: most (if not all) methods for restricting users to some limited
trial period are flawed in some major way; users can take a snapshot of
their machine before installation and after installation and single run,
and determine what has changed to determine exactly what is necessary to
remove such protections.

- Josiah

 

[Dang Griffith]

I'm searching for a good way to provide a "trail
period" (something like 90 days) for a commercial
application that I'm writing. I'd like something
that can easily stop working 90 days after
installation. Can anyone point me to something
that exists already?

Look at http://www.macrovision.com/, formerly (or now owner of)
GlobeTrotter Software. It's pretty easy to use, and you can
set it up so users can "activate" their temporary
copy without having to get a new copy of the software.
--dang

 

[Steve]

Why do you want to break your user's programs to gain money? Will they
not pay for your work without their programs breaking? What does that
say about the value of your work?

In fairness, it might not be Larry's work that he isn't
confident about, but the honesty of his customers.

Larry, how foolproof do you want this trial period to
be? How sophisticated are your clients? How motivated
are they to crack it? What are your motives for wanting
to disable the program? Are you sure your business
model is the best way?

For example, perhaps you would be better off
distributing a free version with reduced functionality,
with the additional functionality only in the non-free
version.

If you want a foolproof mechanism for disabling the
program after the trial period, then Python is probably
not the language for you. Actually, a sufficiently
motivated hacker will find some way to crack your
protection no matter what you do.

Besides, there is one other thing you should consider.
You're not Microsoft. Your biggest problem isn't people
ripping you off by not paying for your software, it is
that people don't even know your software exists.
Perhaps it is worth letting people make free copies in
order to spread the word. Don't think of it as being
ripped off, think of it as advertising.

Just a few thoughts for you to consider.

 

[simo]

Look at http://www.macrovision.com/, formerly (or now owner of)
GlobeTrotter Software. It's pretty easy to use, and you can
set it up so users can "activate" their temporary
copy without having to get a new copy of the software.

You are shitting me right? FlexLM! You know everybody hates that
software as it is such a pain in the arse for the legitimate user?!
Plus of course, it's very easy to hack - jees, you might as well go
back to dongles!

I have no advice for putting a trial period into your software, but I
can say that a function-limited version is certainly not the way to go
- if you're giving out a demo, then it needs to show the user the
power features to impress, so disabling them is stupid.

Maybe disabling saving/printing or something..... Anything which uses
the Windows Registry is just pointless, or even the timestamp of the
install directory.

Of course, today the money is in support, not what comes on the disc,
just look at Linux.

 

[Larry Bates]

My post has gotten some really varied responses.
I've been writing software for over 30 years
so I know that there is no "fool-proof" way
of doing what I want. But I thought someone
may have come up with an "acceptable" solution.
I contribute to this newsgroup on a regular
basis and thought I would at least ask.

I find the idea that you can give the software
away and charge for support an interesting one.
If you write REALLY good software with REALLY
good documentation that provides REALLY good
tracing and debugging support (so users can
track down their own problems), what are you
going to charge for?

The reason I wanted to put a trial period on
my software was that I may have the opportunity
to place it on the CDROM with a hardware device
that is being sold. I would like every end
user to have the opportunity of trying out my
add-on package. I am however, not prepared to
let them run it forever for free. If it provides
value to them, I believe they should purchase a
license. This may put me in the minority on
a Python site, but that's the way I feel.

Regards,
Larry Bates
Syscon, Inc.

 

[Ben Finney]

I find the idea that you can give the software away and charge for
support an interesting one.

So interesting that many 21st-century companies are doing just that.

If you write REALLY good software with REALLY good documentation that
provides REALLY good tracing and debugging support (so users can track
down their own problems), what are you going to charge for?

That is indeed your dilemma. What are you going to provide to the user
that they will want to pay for? They will *not* want to pay for "usage
license", despite the current copyright law. To expect that they will
is to treat them as fools or slaves.

When someone already has the software in their hands, what value are you
going to add that they should pay for? Some existing suggestions:
installation assistance, customisation, integration with other systems,
printed documentation and so on. You can probably think of others.

The reason I wanted to put a trial period on
my software was that I may have the opportunity
to place it on the CDROM with a hardware device
that is being sold.

You may want to treat the hardware as a value add for your software, and
charge a royalty for each bundle sold.

I would like every end user to have the opportunity of trying out my
add-on package. I am however, not prepared to let them run it forever
for free.

You wish, in short, to tell them what they can do with what they have
legally purchased. Would you want others to do this to you?

If it provides value to them, I believe they should purchase a
license.

If you legally mandate this, you will simply motivate them to find a
replacement, or crack whatever protection you put in place, or not
purchase in the first place, depending on their technical ability or
respect for copyright law. Why not allow those who want to pay, do so,
without demanding it?

The principle here is: think of things users would *want* to pay for as a
user of that software, and find a way to provide that. If they can see
the value of paying for something, they'll be much more motivated to do
so than being forced by some intentional flaw in the software.

 

[Roger Binns]

I am however, not prepared to

let them run it forever for free. If it provides
value to them, I believe they should purchase a
license. This may put me in the minority on
a Python site, but that's the way I feel.

Keep a counter of how many times the program has been
run, and how long a time period it has been used for.
Start whining once they get past a reasonable trial
period.

I would store the counters in the registry or somewhere
similar. The user could go in and edit them back down
to zero, but at that point they are trying to immorally
alter the software function to get around the period.
There is no real point trying to deal with people who
are absolutely determined to steal. They will always
succeed. People who have to make minor changes
to circumvent stuff know they are doing wrong.

You can also add in a weekly check for updates (with
the users permission). That will remind people that
they get to pay for the software's continued improvement
(unless 1.0 happens to be perfect and user requirements
never change

Roger

 

[Steve Holden]

My post has gotten some really varied responses.
I've been writing software for over 30 years
so I know that there is no "fool-proof" way
of doing what I want. But I thought someone
may have come up with an "acceptable" solution.
I contribute to this newsgroup on a regular
basis and thought I would at least ask.

I find the idea that you can give the software
away and charge for support an interesting one.
If you write REALLY good software with REALLY
good documentation that provides REALLY good
tracing and debugging support (so users can
track down their own problems), what are you
going to charge for?

The reason I wanted to put a trial period on
my software was that I may have the opportunity
to place it on the CDROM with a hardware device
that is being sold. I would like every end
user to have the opportunity of trying out my
add-on package. I am however, not prepared to
let them run it forever for free. If it provides
value to them, I believe they should purchase a
license. This may put me in the minority on
a Python site, but that's the way I feel.

Larry:

I personally, and many others who read this newsgroup, have no problem
with you wanting to profit by and from your labors. But unless I'm much
mistaken, the majority of end-users will be pretty much completely
bamboozled by even very simple techniques like creating a file or a
registry entry on installation and then timing out unless some
authenticator that only you cna provide is present on the disk.

Even if you regard the majority of users as dishonest, I feel you are
vastly overrating their typical technical abilities.

Bear in mind the python.org webmasters see at least five queries a week
along the lines of "I just found Python on my computer, what's it there
for and can I remove it?"

Good luck with the CD sampler.

regards
SteVe

 

[Ian Parker]

Keep a counter of how many times the program has been
run, and how long a time period it has been used for.
Start whining once they get past a reasonable trial
period.

I would store the counters in the registry or somewhere
similar. The user could go in and edit them back down
to zero, but at that point they are trying to immorally
alter the software function to get around the period.
There is no real point trying to deal with people who
are absolutely determined to steal. They will always
succeed. People who have to make minor changes
to circumvent stuff know they are doing wrong.

You can also add in a weekly check for updates (with
the users permission). That will remind people that
they get to pay for the software's continued improvement
(unless 1.0 happens to be perfect and user requirements
never change

Roger

I second this. People may accept a copy of software from an associate,
or be pleasantly surprised that a visiting engineer has installed some
software on one of their computers. They may gloss over the fact that
it is not licensed.

However, if the only way they can keep the software working is to reset
the date on the PC or to clear some registry entries, they tend to
recognise that this is at least immoral and perhaps criminal abuse.

So give the potential user fully functioning trial software but include
a timed expiry. If it is useful to them, they may well buy it.

Regards

 

[Anton Vredegoor]

I find the idea that you can give the software
away and charge for support an interesting one.
If you write REALLY good software with REALLY
good documentation that provides REALLY good
tracing and debugging support (so users can
track down their own problems), what are you
going to charge for?

Maybe give away the previous version of the software but ask some
money if they want to upgrade to the next version?

If there is yet another new version start giving away the previous
version for free. This way customers are motivated to stimulate
software development processes by their desire to own the latest
upgrade.

The distinction between support and development of the code is made a
bit less strict and you can use that to provide specialized versions
of the code to those who are willing to pay some more. The
understanding should be that everything they pay for could possibly
end up in the free version after some time.

I don't know if it would be wise to negotiate about how much time it
would take before other customers will profit from the new features
for free with some paying customer. Maybe some credit messages in the
documentation like "this feature was added thanks to financial support
by customer x" would be a way to appease feelings of injustice.

Anton