1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

How best to package commercial perl scripts

Discussion in 'General Business' started by nevetS, May 7, 2006.

  1. #1
    I've built a series of perl scripts that act as a thin client integration for a product I work with. I'd like to package them for resale, but I'm concerned about handing off my source code. There are no products in the market at the price point I want to hit - but it will only take one customer to change that if they can see my code.

    These are cgi scripts, so compiling them with perl2exe probably won't do the job - since it wraps the interpreter into the executable. But maybe I'm wrong about that... I expect the scripts to be run on a relatively low volume web server and dealing with no more than 40 simultaneous connections.

    Should I use a code obfuscator? Or should I just leave the source as-is and force the client to give me a signed NDA/License Agreement? Or is a compiled version a realistic option?

    The product isn't that complex - I just wrapped a few existing modules with a custom API to build an integration point - the idea being to enable blackberry/cell phone/pocket PC clients to an enterprise application via a simplified web interface. The lack of complexity is my concern - you won't have to be a perl expert or an API expert to reproduce the code. All the API gotcha's are already worked out in my code and easily identifiable.
     
    nevetS, May 7, 2006 IP
  2. clancey

    clancey Peon

    Messages:
    1,099
    Likes Received:
    63
    Best Answers:
    0
    Trophy Points:
    0
    #2
    It is too bad one cannot easily compile perl code using a C compiler. That would instantly solve the problem of protecting the source. It would not solve the problem of piuracy, though you could always build things into the program which deal with that issue.

    A code obfuscator is probably an important first step. Putting information in a hidden file, which needs to be called would add a further layer of security. However, this probably works best on a *nix box, where you could make the person become root to install. You could make the file readable by all, but hidden and non-writeable by anyone but root.

    The config file name could be a hash of the IP address of the machine and some other obscured value in your program, which can be quickly calculated by the program. It will work if the file exists, fail if it doesn't.

    If you do what DirectAdmin does and force all install to take place via an ssh connection from the IP address of the machine which is licensed to run the program, you could create special values at install time which are used to unlock the functionaility of the program, but the method for creating the value is hidden from the customer. If these are based on the IP address of the machine, then copying the code base to another machine will not result in a working program, unless the IP address is identical.

    DirectAdmin requires people to let them know when they change IP addresses so the licenses for the system can be updated for the new IP. The program phones home once every couple of weeks. If the license won't validate, the system stops running.

    Having said that, I think that when most people pay for something, they tend not to share it with others, especially if you target businesses. If programmers want to duplicate what you offer, they only need to know what it does.
     
    clancey, May 8, 2006 IP