in reply to Re: License key for script
in thread License key for script

I should explain it more clearly, Thanks you have done it form me.

I am looking for...

Are you wanting to write a program in Perl, distribute the source code to the operators of some web server you don't control, and have it not run once a certain date is past?

please help me

Replies are listed 'Best First'.
Re^3: License key for script
by mr_mischief (Monsignor) on Sep 07, 2010 at 05:53 UTC

    It is unfortunate that is what you need to do, because there really is no satisfactory way to give others access to their own copy of your program and enforce a license restriction on it. This is especially true when you provide the source to them.

    There are some possible workarounds. None of them are pleasant. What's worse is that the workarounds for making your Perl code more secure on a server you don't control still don't make rejecting a license or ending a subscription foolproof as a technical measure. Even a compiled program that decrypts most of itself at run time can be broken by a motivated person with knowledge of readily available tools.

    The only reliable way to enforce subscriptions is to control where the code runs. You can do that by running it on your own server and selling access to it or by enforcing the subscription in a reliable and responsive court system. The latter is often more trouble than it is worth.

      Very much agree on it. What I have in my mind is when client sends a request(1st request) for a resource. Server(Requested Server) will check for its subscription on my server and do a database transaction(or set some cookies on client)on requested server.If subscription is over than it may redirect to some other location and is not than it will display the resource.

      What do you suggest.

        Server(Requested Server) will check for its subscription on my server

        So you're saying the service is not provided by code on your server.

        You seem to be missing the point. While it's trivial to write a script that does what you specified, there's nothing preventing the client from changing the script you give them so it doesn't act as specified. Simply inserting "0 &&" will stop the script from doing what you want it to do.

        The problem you are actually facing is "How do I prevent the client from easily disabling the check once he has the script?" And the answer is "It's impossible." Maybe you would settle for making it hard for the client to disable the check once he has the script. At which point, you have to ask yourself "How hard, and at what cost to the user?" Costs include usability hindrances.

        A reply falls below the community's threshold of quality. You may see it by logging in.