Back in the early days of software, licensing wasn't an issue: If you could get to the computer, it was because you were authorized. All user interaction with the system was through the programmers and technicians. If some user wanted to steal something, it would be in the form of 20 tons of steel, wires, and vacuum tubes. Fun? Yes. Easy? No.
Today, it's a different story. Most users are non-technical, and some are unethical. So now we have licensing agreements and teams of lawyers to back it all up. But we also have software, software that can delicately enforce some of the rules. For a particular piece of software, there is still the question of, "How much licensing enforcement code do I add to my application?" The amount of software control you include will fall somewhere in the "freedom-security" continuum shown in Figure 21-1.
Figure 21-1. The licensing enforcement continuum: where are you on it?
If you go for the Freedom end of the spectrum (convenient for users and hackers), you will have to go on the trustworthiness of your users, and any armed guards you have dispatched to their offices, to keep the program in compliance. At the Security end of the scale (secure for programmers and highly paid law firms), the software implements practices and policies that ensure only licensed users of the application ever use or install it; no armed guards needed.
The rest of this section discusses some possible options you could choose within the Freedom-Security range.
License Agreement Only
When you write an application for use only within a specific organization or by a small group of users whom you will have regular contact with, the license-agreement-only method may be just what you need. In fact, I would bet that the majority of Visual Basic applications are in this vein. Microsoft has announced over the years that the vast majority of Visual Basic programmers target their applications for use in a specific business organization, tied to a specific custom database. Such systems often require very little in the way of license enforcement, because the application is useless when carried outside the building where it was meant to reside.
Even if your software achieves widespread distribution, this licensing scheme may still be the way to go. Many shareware applications, including a major operating system that rhymes with "Plinux," use the Free Software Foundation's GNU General Public License (http://www.fsf.org/licensing/licenses/gpl.html) as their primary licensing and distribution policy.
Generated General License Key
If you need a bit more control over the distribution, installation, and use of an application, you can impose a generated general license keybasically a password that allows the application to be installed or used. Such keys are often entered at the start of the installation process, with the user prompted for a specific key. Without the key, it's goodbye installation.
The software vendor will need a way to generate a good set of unique installation keys. There are a few options.
Generated Custom License Key
A custom-generated license key is similar to a general generated key, but uses personal information supplied by the user as part of the generation process. Such a key is more interactive, and requires that the end user specifically communicate with the software vendor (or an application on its web site) to complete the installation process.
During the purchase or installation process, the user makes specific information (such as the owner's name and the date of purchase) available to the software vendor. The vendor then uses public-private key encryption (asymmetric cryptography) to either fully encrypt or digitally sign the relevant information. The encrypted signature is then returned to the end user for installation. The installation process uses the public portion of the key pair to ensure that the signature is valid.
We will use this license key method in the Library Project, so I'll have more to say about it a little later.
License Key with Hardware Identity or Lock
For paranoid software vendors, or for those who have a legitimate need to keep a tight rein on their installation base, there are solutions that involve regular access to hardware or services to confirm that previously installed software is legal and valid. One popular method uses a "dongle," typically a USB port-based device that the software must have access to each time it runs. The software vendor supplies a dongle with the licensed software, and may encode it with date-based or use-based limits.
With the prevalence of the Internet, software vendors also have the option of real-time verification over the Web. Each time the program runs, it could access a known vendor site, and use XML Web Services or a similar method to engage in a usage verification process. Such a system allows for ongoing monitoring of the software by vendors who may have a business or governmental reason to limit use of the software.
For one of my customer projects, I must access a third-party web site on a monthly basis and download proprietary data for use with that vendor's software. The vendor requires that I always access their web site from a specific machine with a specific IP address. It will refuse to supply the data if I attempt to connect from any other machine. If I have a real need to use a fresh IP address (if, for example, I change Internet Service Providers), I must submit paperwork to the vendor informing them of the new IP address. It seems pesky, and it is an irritation. But the data they supply is unique and valuable, and they feel they have a business need to protect that investment. Because my customer requires the data, I have no choice but to comply with the monthly verification procedures.
The highest level of security requires a blatant distrust of the user, although there may be good reason for this. For highly sensitive applications, the software vendor may make their product available to only a limited number of customers, and then only on a lease basis. As part of the lease agreement, the customer agrees to have a trained staff member of the software vendor on-site, running and maintaining the application for the customer. At the very least, the vendor will require that one of its employees be immediately available to the customer whenever the application is used.
In a world of off-the-shelf software applications, it seems unconscionable that such a system could exist. But in high-risk situations, security concerns are raised to such a level that neither party is willing to fully assume the risks of installing and using the application apart from the other.
Although I was tempted to use this system for the Library Project, I think we'll stick with our original plan of employing a custom-generated license key.