>Hello all:
>I have a complex sales system wich consists in several modules. There is one to import data from cell phones, another to export data to major providers, another one to export data to accounting third party software and so on.
>We usually shipped exes to our customers whenever they bought the modules from us, but now, due to the high volume of customers we have and the lack of control this method has, we have tought of bundling all the modules into a single exe (the main exe, the one with the program) and activate them via phone when the user buys that particular module from us.
>The problem is that I have no idea about how we van get this level of control. Since the database especification is open to allow customers to write their own interfaces to their systems, many know our database structure, so a simple table with active modules can easily be hacked.
>Also, there are some needs (some modules are licensed with expiration dates, some others are licensed just for some number of users).
>Can anyone helpme to design the software license framework?

Just some thoughts for this moment.

Why by phone? Is some code told that the user must enter in an input field? Why not some license file that is sent by email?

Think of the several modules as separate products. Each product tests for its own license information. Each product could also eventually be a separate exe.

The license information, let's put it in separate files for each product, needs to be encrypted. So, you'll need an encryption/decryption routine. The encryptor need not necessarilly be distributed, although it may be of help (see later). The routine that decrypts the information has to be in a general library. That library (e.g. an app) needs to be encrypted also, to prevent decryption with e.g. that horrible tool Refox. So, you'll need an encryption tool for your apps and exes. I advise Molebox Pro.

All relevant information must be present in the (encrypted) license file. So, at least number of allowed concurrent users, expiration date, product id, encryption version (!), information about the licensee.

You should try to prevent abuse of a (stolen) license file. I have realized that in this way: A copy (copy!) of the license file is placed in the relevant map (I deliberately use the DATA map, rather than the APP map). The routine that decrypts the file notices that it is an original license file and will do a one time conversion. Actually, in my case it adds information about the 'environment' to the file. (This is why the encryption routine may be of help in the library.) As a consequence, if that file is copied to some other spot, it will (should) fail because the environment differs.

There must be a form in the application where the license information is displayed. I'm of opinion that it's also important to display appropriate information if the license file is wrong.

This is a serious job that will imply several weeks of implementation. You'll meet quite many bears on the road, implications you hadn't expected beforehand.