Ideas for a third version of the licensing code.

Integrate the older “DemoAndLicensing” code with the new license code.
Especially, allow the Evaluation type licenses to have start dates.

Add a “Licensing” menu item to the CERT menu that would let users:
Check the status of the current licenses, including type, name, start date, duration/end date.
Add a new license.
Remove existing licenses.
Choose the order in which licenses will be searched.
Once we allow multiple licenses, have CERT loop through all of them until it finds one that is currently valid.

Make sure all of the new licensing code works on Windows.
Second Licensing implementation.

Information in license:

License type: internal (MPLab use only), evaluation (no output allowed, time limited), licensed.
Licensee name (make sure to validate input if necessary)
License start date (if empty default to the first time CERT is run)
License duration (in days)
Cryptographic hash of the above info, encrypted with our private key. Including information about which hash and encryption functions were used.
Instead, we encrypt the above info with a private RSA key. CERT then decrypts it using the public key.

Use cases:
Tech transfer office:
Run license utility
Enter licensee name
Enter license duration
Enter license start date
Save license info to an xml a license file, including encrypted hash of license info, directly inside the CERT application.

Licensee:
Install CERT
CERT checks internal license file. If not found give error message.
If found display licensee name and end date for license.
If no license is found, assume it is an evaluation version (30 days?) and don’t allow any output.
CERT complains that it’s not licensed and gives two choices: Quit or “Add License”
Add License puts up an open file dialog box.
User navigates to license file and selects it.
Decrypt the hashed license info.
Hash the local license info.
Compare the two hashes. If the same, proceed. If not, give error message and quit.
Copy license file to (in order of attempts):
/Library/Application Support/MPLab/License.xml,
/Users/Shared/.mplab.xml
~/Library/Application Support/MPLab/License.xml.
Continue starting as normal.

Choose “Licenses...” menu item.
Show dialog box with License info (including file location?)
Allow the user to delete the license.
Allow the user to install a new license.

Error messages:
The CERT license period has ended. Please contact UCSD Tech Transfer for a new license or to address any questions. http://invent.ucsd.edu/index_flash.htm
Unable to start the CERT licensed software. Please contact MPLab or UCSD Tech Transfer if you have any questions. http://invent.ucsd.edu/index_flash.htm
Invalid license file. Please contact MPLab or UCSD Tech Transfer if you have any questions. http://invent.ucsd.edu/index_flash.htm
This version of CERT is licensed to [insert].  The license is valid through [insert].

License
Type (internal, eval, paid)
Licensee name
Start date
duration
Internal builds
Don’t output any messages.
Don’t put any limits on output.
Evaluation versions
Do check for the evaluation start date file(s).
Do output time limit messages
Do put limits on output.
Licensed versions
Do check for a license file.
Do output license messages
Don’t put any limits on output.

License Types would be integers, randomly selected. After decrypting a license, if the type doesn’t match one of the known integers we know the license is not valid.

Main interface methods:
isValid
type
licensee name
start date
duration
setLicensePath
setLicenseString
First attempt at License requirements:

This is a list of requirements for a module for adding licensing to the CERT Macintosh application. Its purpose would be to:
1) Restrict use of CERT for each client to a certain period of time.
2) Collect records of how often each client uses CERT.

Users will need to add and remove licenses.
Allow the user to add a license.
Allow the user to inspect licenses. At the least they need to know when they will expire.
Allow the user to delete licenses.
It should be difficult to guess a key.
It should be possible to check that a key is at least a valid one, without contacting the server.
It would also be good if the license expiration date were encoded in the license so we could use that if it isn’t possible to connect to the server.
Possible pieces of info in the license: Client name/number, key, expiration date.

Every time the application is launched:
Send the license back to our server.
Server will respond with the date/time the license expires.
If it’s still valid, allow the app to continue. Store the date/time when the license will expire so we can check it while the app is running.
If not, provide a message then quit.
If we can’t connect to the server?

At some interval while the app is running check to see if we have gone past the expiration date/time that was retrieved when the app launched (i.e. don’t re-contact the server).

Each time the server is contacted we will:
Record the license/client and date/time of the contact.
Record the IP address?

Definitions:
Key: short sequence of numbers and/or letters. Validity can be determined by a formula which selects a sparse set of keys from a larger space.
License: Wrapper around a key plus possible other data.