Hello

It seems like you got two issues mixed up slightly.  One is the licensing issue
and the other is the restriction issue.  Let me elaborate:

Licensing is an agreement between the program supplier and the user regarding
the use of the program, redistribution restrictions, the freedom to modify, ...

You can adopt the licensing agreement most suitable to your needs from many
licensing schemes already available.  Probably by looking at the license
agreement of any shareware application, you will get an idea of how it's done
to limit the number of days the user may use the program before paying or
removing the program.  This is the same whether the program is written in C,
Java, Perl, VB, or any language.  Users are expected to obey the license.

Now if you want to force your users to obey the license, you get into trouble. 
First, assume you can force your users to use the program for n-days, then you
would not even need to supply any other restrictions in your license. 

Can you, using your program, *force* your users to obey the license.  You
already answered by saying that users can simply comment out the check point. 
BTW, this is not a perl limitation.  There exists many decompilers in the
market for decompiling JAVA, VB, and even C compiled binaries.  The quality of
these decompilers differ greatly, but bad decompilers can be thought of as
giving obfuscated code of the same program.  Obfuscation does not help since it
assumes no one (or program)  would be smart enough to reverse it.  

I believe perl compilers come in two flavors: one that actually maps every perl
statement into the appropriate C statement making a C program that is
equivalent to the Perl program, then compiling the C program.  The other type
of compilers translates your program into perl OP-Code which is faster to load
(the parsing step is mostly eliminated).  Since the two programs (yours and the
compiled one) are equivalent, the compiled version can be reversed back to a
different version of your program.  The check points can be then removed.

I believe the compiled perl programs are harder to crack, because of the use of
translation to the C program which is practically unreadable, and then the use
of optimized C compilers which produce binaries that are hard to map back to
the appropriate C functions.  VB programs contain almost an explicit version of
the VB source code making the decompilation into an intelligible program easy. 
For JAVA, look at the JAVA-Decompilers-HOWTO.

So, the bottom line is, you cannot have a 100% safe way of preventing your
users from removing any check point.  (I live in a third world country where
you can get a fully functional version of AutoCAD or 3D-Studio for 5 USD, and
the original version of these software come with hardware dongle)


There is another issue that I would like to leave open which is: Some perl
compilers compile all modules used by the program in order to eliminate module
dependencies.  Your program comes as one file that runs without requiring such
and such modules.  How would this influence your licensing agreement?  Does
your program need to be GPLed if it `use`s a GPLed module?





On Fri, 1 Jun 2001 11:28:47 -0400 , Robin Lavallee (LMC) said:
>  Hi people,
>  
>       Has anyone been able to conceive some kind of licencing scheme in
>  Perl ?
>  That is,  I want to deploy a Perl program that the customer will only be
>  able to
>  use for 30-60-90-30n days. This causes great problem to implement in Perl
>  since
>  the customer could simply comment-out the line that does the check (no
>  matter
>  what kind of check that is). I could use obsufucation technique, but that
>  seems annoying. Anyone has a suggestion ?
>  
>  -Robin
>  





_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Reply via email to