My understanding is this regarding nu-licgen.

Let's say I make a license file on June 1 called aw_list.txt and set it to expire in 3 days (June 4). This 3-day license is used in conjunction with my nu-coder encoded script called moon.php. Someone downloads my software package on June 1. For him, on June 4, moon.php will expire. Now let's say person #2 downloaded the software package on June 3. Using the same files, he only gets to use moon.php for 1 day because aw_list.txt is set to expire on June 4.

My suggestion is for you to build into the nu-licgen/nu-coder products the ability to know when the first useage was and set THAT date as the start date for the expiration period, which here is 3 days. In the example above for person #2, the first use was June 3 and thus his moon.php file would expire on June 6. Is it not possible for you to set things up like this so I don't have to continually generate new aw_list.txt files as each day passes?

Thank you.

Thanks, but it's not really good idea because there is no persistent storage where nucoder might save the date of the first usage.

I'd recommend you to put nu-licgen into your server and generate trial licenses on the fly upon trial requests are comming. If yuu do this, all the licenses will always be accurate.

I would put it in the license.txt file. Why not?

Yes, I will have to try what you suggest. Perhaps this is not as big a deal as my imagination "scares" me into thinking.

Thank you.

There are two reasons:
1) in a normal (secure) environment, Apache web server runs under nobody or dedicated user account that has no write permissions to anywhere on the system except /tmp. So, there is no chance that phpexpress can write to license.txt and keep its firstusage data there (as well as anywhere else).
2) even if we manage to write to this file, we still can't solve another problem. People who want to circumvent the licensing may replace the file with its original copy and they can do this every day so it will be the first usage date and system will run forever.

Built-in expiration time is a more reliable solution.

Also, if it was actually able to detect the 'first-run' date, then it might open the door for users to set the clock forward a few years, run and then set it back.

Keeping the time limitation on the vendor side will always be much more secure and less volatile than any method that you might set up client side. And that's kinda the point of trying to secure it, isn't it? Otherwise you might as well just tell the user to stop using it and trust them to do so.