Distributing a Java app as a TrialWare

D

Dexter

I have developed some application software in Java language that I
plan to distribute to end users as a trialware.

How can I make the Java app work for a limited time. Say for a month

A note to Andrew: This is the feature I tried to implement with
updating a file contained in the Jar file
 
A

Andrew Thompson

Dexter said:
I have developed some application software in Java language that I
plan to distribute to end users as a trialware.

How can I make the Java app work for a limited time. Say for a month

Oh, that is horrible. *
A note to Andrew: This is the feature I tried to implement with
updating a file contained in the Jar file

* To be honest (OK blunt), this is not something I am
likely to expend time helping with.
 
B

Bent C Dalager

I have developed some application software in Java language that I
plan to distribute to end users as a trialware.

How can I make the Java app work for a limited time. Say for a month

Have it call your server every time it launches (and once every 24
hours if left to run for that long) and perform some hard-to-spoof
communication whereby your server tells the app whether it should
function or not. Of course, this requires your users to always be
online when using the app.
A note to Andrew: This is the feature I tried to implement with
updating a file contained in the Jar file

You cannot really achieve this by checking local data and doing local
actions. The user can easily set back his clock, run the app in a VM,
etc., which will tend to screw up your checking.


Note: it is probably a bad idea to do any of the above. It will
introduce entirely new catastrophic points of failure and even if you
get the mechanism to work 100%, it is still going to alienate a number
of potential customers who are really pissed that it just suddenly
stopped working after a month. Even users who don't pay for your app
tend to contribute to your earnings by spreading the word to their
friends, some of whom will pay - /unless/ said non-payers get burned
by sudden deactivation in which case they will instead be telling
their friends how much your software sucks.

But, if you have extensively researched your market and determined
that product deactivation isn't going to have such negative effects on
your target audience, server-based (and probably registration key
based) authentication is the way to go.

Cheers,
Bent D
 
P

Patricia Shanahan

Bent C Dalager wrote:
....
Note: it is probably a bad idea to do any of the above. It will
introduce entirely new catastrophic points of failure and even if you
get the mechanism to work 100%, it is still going to alienate a number
of potential customers who are really pissed that it just suddenly
stopped working after a month. Even users who don't pay for your app
tend to contribute to your earnings by spreading the word to their
friends, some of whom will pay - /unless/ said non-payers get burned
by sudden deactivation in which case they will instead be telling
their friends how much your software sucks.
....

Deactivation does not need to be sudden. I've used trial ware that
showed a dialog each time it started pointing out that it is trial
software and saying how many days remain.

Patricia
 
D

Dexter

seehttp://mindprod.com/jgloss/installer.html

A very simple scheme just pokes the install date into the registry
using the Preferences mechanism.

Seehttp://mindprod.com/jgloss/preferences.html

Thanks Roedy, thats exactly what I needed

Regards

Asad
 
H

Hunter Gratzner

Thanks Roedy, thats exactly what I needed

That's hackable in less than five minutes. I wouldn't consider it
worth the lines of code needed to implement such a "protection".
 
P

Patricia Shanahan

Hunter said:
That's hackable in less than five minutes. I wouldn't consider it
worth the lines of code needed to implement such a "protection".

It may be useful for honest but forgetful users, by reminding them that
it is trialware and how long the trial has to run.

Patricia
 
R

Roedy Green

That's hackable in less than five minutes.

Depends on your audience. Your average user today could not even
delete or restore a file, much less probe the registry.

Just a bit of camouflage for the key and value should do it for 99% of
your users.
 
B

bbound

Depends on your audience. Your average user today could not even
delete or restore a file, much less probe the registry.

Just a bit of camouflage for the key and value should do it for 99% of
your users.

Why are you helping him to do something as evil and stupid as make his
software less useful and less valuable after going to all the work he
has to make it in the first place?
 
H

Hunter Gratzner

Depends on your audience. Your average user today could not even
delete or restore a file, much less probe the registry.

But your average user can operate a torrent client just fine.
Just a bit of camouflage for the key and value should do it for 99% of
your users.

And all it takes is one of the remaining 1% to hack it and place it on
a p2p network.
 
R

Roedy Green

And all it takes is one of the remaining 1% to hack it and place it on
a p2p network.

If you are worried about a dedicated hacker cracking your code, you
probably should not even be distributing class files.

See http://mindprod.com/jgloss/obfuscator.html

Frequent updates with slight variations in obfuscation might be the
best defence, even if the updates are utterly trivial. Your hacker
will get bored recracking your code. He is doing it for the
challenge.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top