Re^3: License key for script

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.

Comment on Re^3: License key for script

Replies are listed 'Best First'.
Re^4: License key for script by shanu_040 (Sexton) on Sep 07, 2010 at 06:33 UTC
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.	[reply]
Re^5: License key for script by ikegami (Patriarch) on Sep 07, 2010 at 07:44 UTC
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.	[reply] [d/l]
A reply falls below the community's threshold of quality. You may see it by logging in.