-   Programming (
-   -   Implementing a time expiration in Fortran (

suicidaleggroll 12-19-2013 11:58 AM

Implementing a time expiration in Fortran
We have a client who will be licensing a program from us for one year. We will be providing the hardware and setting up the OS as well, so we're just going to provide an executable for the program rather than the source (they're not interested in the source anyway).

Normally we would just leave the one year license up to a "gentleman's agreement", but the client has insisted that we add a time bomb to the code with a separate license file that will cause it to quit working after a year.

I'm looking for suggestions on the best way to go about this. I was thinking that maybe the license file could just be an encrypted expiration date, and the program would decrypt it and compare to either the system clock or an internet time server to determine if it should continue executing or not, but does anybody have a better suggestion?

rtmistler 12-19-2013 12:11 PM

I think your idea is fine and just make sure that it cannot be readily reverse engineered where someone can do replacement of numbers and have it work. Like use a very lengthy key to encrypt the date and other information to generate and validate their license. Or even use 12 different key values and use a each one depending on the month the license was created for.

Fortran? I do not believe I've used that in over 30 years. (Or did you do that just to garner notice?)

rtmistler 12-19-2013 12:13 PM

You'll have to provide an app for the client to generate the licenses, of course.

I'm thinking also, little worth in trying various ways to detect and work around the end users changing their system date. You can try stuff, but ultimately they'll still try their own tactics too. Plus a lot of stuff I've had on limited licenses works exactly that same say, if I reset my date, they'll work, but then I have to always reset my date and that's a problem for a working system with email or development, etc.

chrism01 12-22-2013 06:13 PM

Just checking the date is often sufficient, at least on Prod systems.
2 reasons:
a) most people don't fool with the date on prod because it breaks important stuff
b) it becomes a pain to keep doing it; eventually they'll give in and buy another license.
If they automate b), see a)....

Also, as they've asked for it, it sounds like they're keen on remaining 'legal'.
You could also add job in your system to remind you to contact them in a year and remind them/drop support for them ....

sundialsvcs 12-23-2013 09:17 AM

A very, very simple program that embeds a license-number and expiration date into a readily changeable file and/or registry-entry (on Windows) will do the job. (In fact, on Windows, a built-in licensing infrastructure already exists.)

A good friend of mine once had a very expensive 12-string guitar in a cardboard case with the tiniest imaginable padlock on it. The lock was there, he said, "to keep the honest people out." :eek: I have never forgotten this.

suicidaleggroll 12-24-2013 09:54 AM

Thanks for the suggestions. I ended up going with an aes-256 encrypted expiration date for the license code. The program decrypts it and compares to the current system time before proceeding. The licenses are easy to make and easy to use, and should be pretty transparent to the end user until it expires.

They could change their system time to temporarily get around the expiration, but that would end up being a royal pain long term, and would break a lot of the supporting codes unless they immediately changed the date back. I didn't want to use an internet time server because I didn't want to force them to have to have internet access any time they wanted to use the program. It goes back to the whole DRM problem - the harder you make it for hackers to break, generally the harder/more painful it is for legitimate users to just use it like they're supposed to, which pisses people off and in my opinion is a bad move.

Besides, I'm under the impression that they didn't want this timeout for our protection, they wanted it for their protection, to keep them from accidentally breaching the license agreement by using the program past the expiration. In which case, there's no need to worry about them trying to get around it.

It is Fortran BTW - Fortran 90 to be more precise. It's in the atmospheric science domain, where Fortran is still the go-to.

All times are GMT -5. The time now is 06:53 PM.