ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
Last edited by suicidaleggroll; 12-19-2013 at 12:59 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?)
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.
Just checking the date is often sufficient, at least on Prod systems.
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 ....
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." I have never forgotten this.
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.
Last edited by suicidaleggroll; 12-24-2013 at 10:57 AM.