Registering and License Keys

[Anonymous Monk]

Hi,
I have developed some rather nifty auction software, it's taken me ages and I want to distribute and sell it over the internet. I'm happy for people to download and install it themselves, but then I want to ensure that they pay me for using the software. What is the best way of doing this?

Is the best way to provide the software free, then provide a license key upon payment being recieved. If a license key isn't entered then the software shows a big 'THIS SOFTWARE IS NOT LICENSED' message across the users screen.

How can I implement this when all the code is totally viewable by the person who downloads it? I want to ensure they can't just hack the code and take out the 'THIS SOFTWARE IS NOT LICENSED' message.... is there any way to encrypt the Perl code (you can do this with PHP code)?

Your thoughts on this matter would be very much appreciated!

Thanks,
Tom

[diotalevi]

I think, perhaps, you've done your business planning all the wrong way around. This is the sort of thing you should have figured out before doing something that "took ages." In general you've picked up a particularly hard problem. The short answer (which is all I'm inclined to write right now) is that you have a choice - either encrypt the program and don't allow access to it without a key or just put some technical barriers in place but nothing that ultimately prevents access.

Before going on I want to note that your PHP code isn't encrypted - it's just compiled. This distinction is important because the rest of this note relies on this information. Its like the difference between a novel published in two languages. You may only be able to read one copy but that doesn't mean that someone else can't read both.

The first choice - encryption looks like this: your customer may download the program but it is unuseable without the key. Once you give your customer the key then you've allowed them to unlock a "safe" and get a novel out (of whatever language). At this point the user may or may not futz with their copy or do whatever they want. The point is once a program is useable it is also readable and modifiable.

The other way to go acknowledges that security is impossible and just attempts to make life hard on the potential user. I'm not inclined to help you with this part but I will give you a pointer to the ACME:: namespace on CPAN. There are a few modules that may help with your source-code-obfuscation endeavor there.

---

Seeking Green geeks in Minnesota

[Basilides]

Yeah, Buffy it!! ;-)

[clairudjinn]

Oh for crying out loud, this is intended to be professional software, use ACME::Bleach instead. :)

[cecil36]

Being in technical support for a software company, I can offer you the following advice. If you want to make money off of your work, I would offer the license for purchase with technical support. If someone contacts you, they will need to provide you with some type of data indicating that they are a registered user and are elgible for support. One suggestion on registering users is to have a process embed a serial number into your code, then in your records, have that particular serial number linked to an end user. It will allow you to see who is registered, and also see who is pirating your code by running it on more computers than were actually licensed for use. This way, if someone calls or writes in with unregistered product and needs help setting it up to run on their server, you can flat out tell them that unless they register their product, they will not receive support.

This is how I would recommend setting up your tech support system:
• Have a user visit your product's webpage, and link them to a form that they can fill out with support questions, or have a number where they can call you to recieve live support.
• Put a field in there for the serial number for their licensed product and make it required that the field have a value for submission.
• Have the form be processed as an e-mail on the server side and sent to a special e-mail account. Have a script parse out the serial number and look it up in a database of all registered users. If there's a match, forward to your inbox for follow-up, else reply back to the user indicating that unless they register, they have no support.
• If you are providing live support over the phone, prior to answering questions, ask them for their registration info. If they provide it, look it up to verify it, otherwise *click*.

[diotalevi]

This is actually a very good idea. You probably shouldn't install a serial number into the program - just put that on the contract document you signed with your customer. You can approach non-contract bound users as potential customers. If you do all the usual dance with trademarks and copyright and appropriate legal backing you should be alright.

---

Seeking Green geeks in Minnesota

[cecil36]

Good idea. However, if the means of distribution is over the Internet, our fellow AM (anonymous monk) can work with a company such as http://www.digitalriver.com to handle the purchasing and electronic distribution. In exchange for a portion of the sale as a commission, Digital River will set up your online ordering and notify you of sales. With my employer, they can provide our software product for download and automatically assign a serial number and provide it upon confirmation of the purchase. At the end of each day, Digital River provides us with the info on what was purchased, and we input that into our database manually. I would recommend a setup similar to this.

For a demo user, I would make a separate build of your script, and license it "FOR EVALUATION ONLY". Water down the evaluation version if you so desire so the customer has an incentive to purchase the full version (a la "lite" version). Keep a separate log of these downloads, and support these people for only a short period of time, then if they call or write back after the evaluation period has expired, then either refuse them support, or offer them the full version.

[Anonymous Monk]

cheers for the help guys, much appreciated. I tried buffy'ing it but i've been having a few problems.

I can get this code to buffy and still work:


#!c:\perl\bin\perl
use Acme::Buffy;
print "This is a test\n";


but when I change it and try to view through a browser with code like this:

#!c:\perl\bin\perl
use Acme::Buffy;
print "Content-type:text/html\n\n";
print "This is a test";


it doesn't work anymore and I just get Internal Error. What am I doing wrong? Doesn't Buffy work for web scripts???

Thanks,
Tom

[mattr]

I find the big unregistered banner offensive and distracting myself. How about..

- you could also run it as a service for a monthly fee, hopefully marketed by isps to their customers.

- or offer registered users a private mailing list with new plugins at discounted prices.

- or crippleware, but provide screenshots so they can see exactly what they'll be getting.

- or half way through, you let them enter sample products into an auction on your site (or you provide a demo site). if they bite, let them download a public key encrypted version of your source code. once they pay you, you send them their unique private key. giving them source code is a positive thing, and they need it.

- conceivably you could search for it on google and tell the difference between sources with md5 or statistical analyses of white spaces or perhaps embed info tags which don't show up like the width in pixels of a transparent gif, or the hex digits of font color tags. maybe encode a key in the background colors of cells in a table? :)

- seriously you could probably embed a liscense number in a single color tag, that's easy to interrogate and will cover way more users than you will have.

</feeling lower-case>

[Anonymous Monk]

yeah thanks for that, some really good ideas, pushing it to ISPs is a great idea, then they could push it to their customers = big bucks for me :-)

[Ryszard]

Co-incidently I wrote a small routine that may do what you're after, altho' you'd have have to provide the license key before the software was unencrypted. (ie if you wanted to protect you're software you may have to turn it into crippleware.)

Its not foolproof, nothing is, but it may go 1/2 way to meet you're requirement. You can find the proof of concept code here.

[Mr_Person]

Whatever approach you take, it will probably envolve encrypting or obfuscating the source in some way. There was an interesting discussion on this just a week ago, Encrypted Perl?.

[japh]

You could cripple important functionality (like the final step in processing an order) and email the few remaining lines of critical code in a standalone .pm to users who pay.

You could sell a service. Bloggers can download a multitude of software but many pay a monthly fee for the simplicity of click-and-go blog web sites. Like the support services suggested in other posts, hosting services can be tacked on to just about any software business model.

You could use google to find unregistered users running your software and send your accountant and lawyer after them. If the user circumvented the register.pm mechanism above, then tack on a DCMA bonus.

You could sell auxilliary services besides support. Coordinate having your software suite's interface and documentation translated into different languages, and take a percentage.

You could put 'THIS SOFTWARE IS NOT LICENSED' across all of the graphics you supply and sell the replacement pack. Have lots of little graphics so that it would be tedious to replace every single one. This preserves all your functionality for demo purposes while limiting its commercial potential.

Failing all else, have your software email you any credit card numbers it receives.

Anonymous_Monk, please message me. I want to know more about this auction software.

update: mattr made all my points for me. never mind.

The largest peace protest in history is happening this weekend

[Anaximander]

there are ways to compile the perl code into an executible.. like perl2exe , although you need to be careful depending on what system you are planning to run the code in. i know of no way to encrypt a perl script.

[lofichurch]

I would have to agree, that if you want to use license codes to turn on/off functionality, I'd suggest going with a pre-compiled version, either with perl2exe or perlapp. Either way, you're looking at a greater level of support, considering that these may not always run properly on all platforms (and certain platforms, for sure, are automatically excluded). They will, however, hide your code from all but the dedicated. I wouldn't expect to get perfect protection from any route, we've seen how much money and effort big-named software companies spend on copy-protection schemes using everything from simple codes to hardware dongles, and yet, you can still find cracked versions of the most expensive stuff out there.




That being said, a simple hash-based key and pre-compiling your source in some way (although, really, perl2exe and perlapp just include the source and the perl interpreter together, for the sake of discussion, I'll call it 'compiled') will be inoccuous enough to say that someone mightj ust buy it (if they like it).



!c

[coldmiser]

What I would do in your situation is in two parts.

First, I would make a trial version that would have limited abilities

Secondly, I would make the software look for a "registration database" located on YOUR web site, that way the software wouldn't be registered to a perticular user but to a domain. If the domain isn't in your database, add them and increment their 'trial' flag each time the program starts, when they have reached a specific number you can disable the product
If the domain is in your database you can pass a 'registration key' back to the program and it will work as designed

With this method, you also don't have to worry about people passing out the registration serial number to a group like 'serials 2000'

I know it's a lot more programming, but I have a feeling it would be worth it in the long run.

[Anonymous Monk]

I personally like the idea of a registration database kept somewhere on your site. You'd want to make sure that the registration keys are time limited and specific to requesting site. For example, the program requests a key from the license server, the server verifies the registration (by the sender's public key) and then replies with a pgp encoded payload consisting of the requestors IP, a time stamp, and a license expiration date. Assuming that the pgp is decrypted properly the software is unlocked to run on that IP (or domain) for some period of time (say 48 hours). The use of pgp is pretty crucial though as it provides verfication of the requestor and assures the veracity and timeliness of the license. If user requests a demo license you can do something like provide a time limited license key that explicity locks off portions of the functionality. Obviously none of this prevents people from trying to hack your source code to remove the security checks. However, if you do it properly you can make it more difficult and probably buy enough time and money to have the code ported to C.

[Massyn]

The problem with this idea, is that a proficient perl coder could still go into the script and change it not to go to a central database. The idea does have merrit, so maybe combine it with a bit of obfuscation, making it real difficult to determine where the database call is made, could pay off in the end.

...

Thanks!

#!/massyn.pl The early worm gets caught by the bird.

[coldmiser]

Yes, a proficient perl coder could disable to 'registration database' check

However, a 'proficient perl coder' could create his own app too!