Trial Version Expiry

[Peter Ardis]

I would like to set up the ability to allow someone to use my solution on a trail basis. So they download it, open it, the time starts counting down, then 30 days later they can no longer login. Can I set this up with a timestamp function?

[Sunshein]

A better way may be to limit the number of times the software can be opened, and in the closing script check to see if the user kept it open for multiple days which could then trigger a function to allow only 1 more opening of the software or no more uses depending on the number of days it was open. I would insert a dialog box to inform the user as to his or her remaining uses.

[Ender]

Ether way, you'd need to have a one record table to store the initial launch information or count. Then refer to that in the opening script. This means the solution would have to be locked down (with no direct access to that table, the database definitions, or ScriptMaker) so the user can't override it.

 

BTW: One protential problem with the date stamp technique is someone resetting their computer's clock to bypass the lockout. You may or may not care to deal with this by additional checks or flag-setting.

[Sunshein]

Thanks Ender for your thoughts and thanks Peter for asking the original question.

 

The program can always be reloaded and open again, but I suspect the user would only do it once or twice.

 

You could include a unique password which would allow the user to go back into the program and use it normally after buying the authorized password, but keep your licensing agreement in place for both a trial version and a full operating version. Your opening script should include a look to see if the user has agreed to the licensing provisions in both situations, and then a look to see if an authorized password is in place. In the separate table, as Ender mentioned, include fields for uses, dates, agreement to license, and password entered and user name.

 

There are several more options you could include in this process. If you need help, contact me directly.

[Jack Rodgers]

You could of course go first class and have your demo log into your web site, time stamp itself and then check everytime it is opened. If it exceeds a value on your site, it stops working.

 

Since you could 'valueize' each demo with your own code number, this could not easily be overcome.

 

There is also the idea of a fixed number of records and no more can be added. This doesn't lock the user out but keeps them from using it after they have created 20-50 records, whatever.

 

It may be friendlier to give them look access in this fashion than no access at all.

[Peter Ardis]

A lot to think about here. I like your shared optimism. I would like the control that Jack suggests through my web site and see myself getting there in time, but it may be out of my league.

 

Jack anything you could send me to read on 'valueizing' and coding would be greatly appreciated. Also, the fixed record number may work fine. So, when they pay in full for example, I give them a password that gives unlimited access?

 

Ender any hints on using a timestamp script in this type of setting to create a 'lock down'. I really cannot conceptualize how that function works.

 

Sunshein thanks for the offer. I will play with it to see what I come up with and get back to you. Which may not be soon. Perhaps email me at peterardis@esdnl.ca with contact info.

 

Thanks all.

[hugh71158]

You could of course go first class and have your demo log into your web site, time stamp itself and then check everytime it is opened. If it exceeds a value on your site, it stops working.

 

Since you could 'valueize' each demo with your own code number, this could not easily be overcome.

 

There is also the idea of a fixed number of records and no more can be added. This doesn't lock the user out but keeps them from using it after they have created 20-50 records, whatever.

 

It may be friendlier to give them look access in this fashion than no access at all.

 

Hi,

 

can you give me more details on how to set up these methods?

 

Regards,

 

Hugh

[JeffGagne]

There is also the idea of a fixed number of records and no more can be added. This doesn't lock the user out but keeps them from using it after they have created 20-50 records, whatever.

 

It may be friendlier to give them look access in this fashion than no access at all.

 

I support this option. Your intent, should be, to get peopel to buy. You want to keep your product on their radar. Why would you want to lock them out? What possible benefit can there be to you? Better to limit their use to XX number records that allows them to get a taste of your product and allow them to evalaute it based upon their schedule not yours.

[Ted S]

One thing to consider is the fact that the prospective customer may not have internet access. Now I know that it is pretty rare for a person not to have internet access nowdays but there are times when internet access is not available.

 

I have a couple youngsters with pretty full calendars so I frequently take my laptop along to skating lessons, gymnastics, swimming lessons, etc. Anyway, I sometimes find this to be a good time to try out new software. If I had to rely on an internet connection I may just decide to take a pass on the software for that reason alone.

 

Something to consider.

[Jack Rodgers]

One other point, you might consider deleting all records on quit/open so the user gets a blank database to use.

[zenith]

Your installer software could also incorporate an expiry date for installations, In the past I've found limiting the number of records in demos is the way to go

[kirkrr]

A recent product I wrote, had the code in it for simple license management, that would also support your demo.

 

A screen, accessible only to the right account, had radio buttons for:

Max # of Assessment

Number of Days

Whichever comes first

Whichever comes last

Never (unlimited site license)

 

The Max count was set by this same non-client accessible admin account.

 

The date was set in a global field on first run, and compared with the current date. I did not worry about changing the system clock, as the client was able to bill a 3rd party on assessment completion, and the system stamped date would have to be timely.

 

The license check code was a bunch of nested conditionals, but works great. It had to be checked on login, and again when a new assessment (record) was created, still providing access to existing data, but no new records after expiration.

 

An authorized user (after getting paid for the new license) could login at the customer site, and reset the date, qty, and expiration flag, allowing them to continue with their historical data.

 

I was working on a one-time password scheme, so I could provide the customer with the code remotely, after paying the license upgrade, but never got that off the ground.

[ejb190]

I had a similar line of thought with an application I developed, but came up with a totally different solution. My application is print intensive and depends, to a certain extent, that I customize the application to each county fair that uses it. My trial versions are totally functional, but I because lock the fair name when I sell it, trial versions have "Trial Version" or some other county's name on it. Kind of looks bad on invoices and checks if the paperwork has the wrong name on it.

 

Just a totally different way of looking at the problem that may or may not work for you.

[hugh71158]

Hi,

 

what about a maximum number of records in the trial version - then sending them an update file with their NIC number (which is easily obtained) after they buy. They run the file, the NIC number is inserted, and the file will only run on authorized machines. Stops copying of your solution.

 

The maximum number of records can be controlled through a New Record button. I have it as:

 

File opened with full access password = file runs with no restrictions.

User access. New Record button clicked - less than 5 records, new record created.

5 or more records - dialog opens saying record cannot be created, please upgrade.

 

Hugh

[kirkrr]

Hi,

 

what about a maximum number of records in the trial version - then sending them an update file with their NIC number (which is easily obtained) after they buy. They run the file, the NIC number is inserted, and the file will only run on authorized machines. Stops copying of your solution.

 

The maximum number of records can be controlled through a New Record button. I have it as:

 

File opened with full access password = file runs with no restrictions.

User access. New Record button clicked - less than 5 records, new record created.

5 or more records - dialog opens saying record cannot be created, please upgrade.

 

Hugh

 

I like it, but I think in some situations, a slight implementation change would be in order - no password, but an unlock code.

 

In single user runtime solutions, an account/password is a painful addition. However, an unlock button on a preferences screen could be set up to write a global, do not change value if exists, field, that could be checked at startup or new record. This button would require a password, or keyword, to set the "unlocked" field. You could change the keyword in new revisions of the program to keep people from unlocking new versions with old codes.

 

If the field already has content, unlock would do nothing, and without the unlock code, the field could not be set. Whether you store that keyword programmatically, or in a field to compare to input, the process would work!

[hugh71158]

I like it, but I think in some situations, a slight implementation change would be in order - no password, but an unlock code.

 

In single user runtime solutions, an account/password is a painful addition. However, an unlock button on a preferences screen could be set up to write a global, do not change value if exists, field, that could be checked at startup or new record. This button would require a password, or keyword, to set the "unlocked" field. You could change the keyword in new revisions of the program to keep people from unlocking new versions with old codes.

 

If the field already has content, unlock would do nothing, and without the unlock code, the field could not be set. Whether you store that keyword programmatically, or in a field to compare to input, the process would work!

 

 

Hi,

 

maybe I was unclear. The first option - file opened with full access password - is only for me, so that I have unrestricted use during development. This option is not available at user level.

 

The only thing that concerns me about your suggestion is a user duplicating the original file (or just keeping the zipped file) and passing it around. If you solution is particular to one industry, and a user has a lot of contacts, sharing could be a problem.

 

I am using an updater to insert the users NIC number into the full version (harvested by running a small file then emailed automatically to me). The end result is a file that will only run on the machines that are approved, and if someone uses it on an unapproved machine I get an email telling me who the original solution was supplied to.

 

Seems to work, but always looking to improve. smiley-smile

 

Hugh

[kirkrr]

That's a good point - piracy of the original file is a hard thing to stop.

 

If there are reports as part of the product, having the registered name print on every report is a slight deterrent - but not a real big one. If people want to steal it, they will.

 

Validation against a company database, like FM activation, works, but requires an internet connection, which only eliminates a few these days. Your NIC combined with a remote validation process would be good.

 

Any idea how to implement this remote activation validation scheme?? :confused:

[hugh71158]

That's a good point - piracy of the original file is a hard thing to stop.

 

If there are reports as part of the product, having the registered name print on every report is a slight deterrent - but not a real big one. If people want to steal it, they will.

 

Validation against a company database, like FM activation, works, but requires an internet connection, which only eliminates a few these days. Your NIC combined with a remote validation process would be good.

 

Any idea how to implement this remote activation validation scheme?? :confused:

 

 

 

Hi,

 

ok, well bear in mind that you stand in the presence of a novice! smiley-laughing

 

I have built a solution, whilst learning a little Filemaker stuff along the way, primarily for my own uses. But, some people have asked me to sell them the solution so it is expanding a little.

 

At first I would give the buyer, at time of online purchase, a link to download a file I called a Code Generator. It was a runtime, they executed it, filled in their name and O.S., clicked a Generate Code button (this harvested the NIC and set in into a field) and then pressed the Send button. Everything was automatically emailed to me.

 

With this info all I needed to do was open the solution file, paste in the NIC number (and also their company name, as it was part of this process and appears at the top of each page in the solution), change a couple of settings, and upload a runtime for them which they downloaded.

 

It all seems like a lot, but it would take me around 5 minutes to do the work. I then improved on this. Now, I am taking a different route.

 

Allow the user to download the demo, scripted as previously discussed in this thread (i will attach a sample grab in this post) If they purchase, then they run the Code Generator and send me their details. I have a file with a locked layout which I insert the NIC and company name info into, and upload it. They download it, and use the Import command from the demo file to pull in their NIC number for comparison with the machine(s) they are using.

 

Although they would need Filemaker to open the file I upload, they do not need Filemaker to import from it - they can do this from the runtime demo. This way I can upload a very small native Filemaker file as opposed to a much bigger runtime file.

 

It all takes a couple of minutes of my time, but they can only use the files on approved computers. If someone tries to run it on another machine I get an email, and it tells me who the original file was registered to (through the Company Name filed) Last month, I sent a polite email to someone saying the file had been used on an unauthorized machine, and were the the original user just using a different computer, blah, blah. An hour later the person bought the solution.

 

I have included my script, it is used in the New Record command. Blurred stuff out as names may change! smiley-laughingsmiley-laughing Also included the Code Generator interface.

 

Hugh